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Preface 


This guide provides STREAMS kernei-ievei programming information 
that is specified by the i SO Data Link Service Definition Di S 8886 and 
Logicai LinkControi Di S 8802/2 (LLC). Where the two standards do not 
conform, DiS 8886 prevaiis. 

This guide assumes famiiiarity with theOSi Reference Modei 
terminoiogy, OSi Data Link Services, and STREAMS, it is organized as 
foiiows: 

Chapter 1 Introduction to DLPI 

This chapter provides an overview of DLPi, inciuding 
addressing information and information on DLPi 
services. 

Chapter 2 DLPI Primitives 

This chapter describes iocai management primitives, 
connectioniess mode primitives, raw mode primitives, 
and primitives to handieXi D and TEST operations. 

Appendix A Sample Programs 

This appendix contains sampie programs for 
connection mode, connectioniess mode, and raw mode. 
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Introduction to DLPI 



Introduction to DIP I 


The Data Link Provider I nterface (DLPI) is an industry standard 
definition for message communications to STREAM S-based network 
interface drivers. A service provider interface is a specified set of 
messages and the rules that allow passage of these messages across 
layer boundaries. 
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HP DLPI Features 

Hewlett-Packard's implementation of the Data Link Provider I nterface, 

HP DLPI, conforms to the DLPI Version 2.0 Specification asaStyle2 

provider. HP DLPI offers data link service users: 

• Clone (maximum 900) and non-clone (maximum 100) access. 

• Support for Ethernet/I EEE802.3, FDDI, Fibre Channel, lOOVG and 
Token Ring. 

• Support for connectionless and connection-mode services 
(connection-mode services are supported only over IE E E802.3 and 
Token Ring). 

• Also support for raw-mode services. For details on raw mode, seethe 
DL_BI ND_REQ, DL_H P_RAW_REQ and DL_HP_RAW_I ND 
primitives. Raw mode is supported on Ethernet/802.3, FDDI, Token 
Ring, Fibre Channel and lOOVG. 

• Style 2. 

• l_STR iocti is supported for doing device-specific control/diagnostic 
requests. 

• Priority messages are supported over lOOVG (see 
DL_UNIT_DATA_REQ primitive). 

• For support of third-party devices, refer to the third-party user 
manuals. 

• Support for the following HP products: Ethernet/I EEE802.3, FDDI, 
Fibre Channel, lOOVG and Token Ring. 

• The following devices support all levels of promiscuous mode: NIO 
ethernet LAN,J 2146A (HP-PB) NIO LAN only (the36967A-20N 
(HP-PB) card is NOT supported), CIO ethernet LAN driver. Series 
700 core and HP EISA LAN. For support of third-party devices, refer 
to the third-party user manuals. 


NOTE The H P ATM adapter provides its own "native" DLPI provider, which 

should not be confused with this DLPI provider. 


HP DLPI does not currently include: 

• Duality of Service (OOS) management. 
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• Connection Management STREAMS; DL_SUBS_BI ND_REQ and 
DL_SUBS_UNBI ND_REQ over connection-oriented STREAMS. 

• Acknowledged connect ion I ess-mode services. 

Device File Format 

The following is a description of the device file formats required for 
accessing the STREAMS DLPI LAN driver. 


Name 

Type 

Major # 

Minor # 

Access 

/dev/dlpi 

c 

72 

0x77 

Clone access 

/dev/dlpiX 

c 

119 

OxX 

Non-clone access 


NOTE HP DLPI supports up to 100 non-clone device files. HP recommends that 

device file names follow the naming convention /dev/dipix, where x is 
the number of the device. 


Header Files 

There are two DLPI header files: dipi. h and dipi_ext .h. Both are in 
/usr/inciude/sys. dipi .h contains definitionsfor thestandard DLPI 
primitives. dipi_ext .h contains definitions for the HP extended DLPI 
primitives. 
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The Data Link Layer 

The data link layer (layer 2 in theOSI Reference Model) is responsible 
for the transmission and error-free deli very of bits of information over a 
physical communications medium. The mcxdel defines networking 
functionality at several layers and service providers between the layers. 

A model of the data link layer is presented here to describe concepts that 
are used throughout this guide. It is described in terms of an interface 
architecture, as well as addressing concepts needed to identify different 
components of that architecture. The descri ption of the model assumes 
familiarity with the OSI Reference Model. 

The Service I nterface 

Each layer of the OSI Reference Model has two standards: 

• one that defines the services provided by the layer. 

• one that defines the protocol through which layer services are 
provided. 

DLPI is an implementation of the first type of standard. It specifies an 
interface to the services of the data link layer. Figure 1-1 illustrates how 
DLPI performs this function. 
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Figure 1-1 
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Abstract View of DLPI 



The data link interface is the boundary between the network and the 
data link layers of theOSI Reference Model. The network layer entity is 
the user of the services of the data link interface (DLS user), and the 
data link layer entity is the provider of those services (DLS provider). 
This interface consists of a set of primitives that provide access to the 
data link layer services, pi us the rules for using those primitives (state 
transition rules). A data link interface service primitive might request a 
particular service or indicate a pending event. 

To provide uniformity among the various UNIX system networking 
products, an effort is underway to develop service i nterfaces that map to 
the OSI Reference Model. A set of kernel-level interfaces, based on the 
STREAMS development environment, constitute a major portion of this 
effort. The service primitives that make up these interfaces are defined 
as STREAMS messages that are transferred between the user and 
provider of the service. DLPI is one such kernel-level interface, and is 
targeted for STREAM S protocol modules that either use or provide data 
link services. I n addition, user programs that wish to access a 
STREAMS-based data link provider directly may do so using the 
putmsg(2) and getmsg(2) system calls. 

Referring to Figure 1-1, the DLS provider is configured as a STREAMS 
driver, and the DLS user accesses the provider using open(2) to establish 
a stream to the DLS provider. The stream acts as a communication 


18 


Chapter 1 






Introduction to DIP I 

The Data Link Layer 


endpoint between a DLS user and the DLS provider. After the stream is 
created, the DLS user and DLS provider communicate via messages 
discussed later. 

DLPI is intended to free data link users from specific knowledge of the 
characteristics of the data link provider. Specifically, the definition of 
DLPI hopes to achieve the goal of allow! nga DLS user to beimplemented 
independent of a specific communications medium. Any data link 
provider (supporting any communications medium) that conforms to the 
DLPI specification may be substituted beneath the DLS user to provide 
the data link services. Support of a new DLS provider should not require 
any changes to the implementation of the DLS user. 

Modes of Communication 

Although DLPI supports three modes of communication, 
Hewlett-Packard supports connection and connectionless modes. The 
connection mode is circuit-oriented and enables data to be transferred 
over a pre-established connection in a sequenced manner. Data may be 
lost or corrupted in this service mode due to provider-initiated 
resynchronization or connection aborts. 

The connectionless mode is message-oriented and supports data transfer 
in self-contained units with no logical relationship required between 
units. Because there is no acknowledgment of each data unit 
transmission, this service mode can be unreliable in the most general 
case. However, a specific DLS provider can provide assurance that 
messages will not be lost, duplicated, or reordered. 

Raw mode interface is also supported. Raw mode allows the DLS user to 
send and receive packets with complete LLC and MAC header 
information. 

Connect! on-mode Service 

The connection-mode service is characterized by four phases of 
communication: 

• Local Management 

• Connection Establishment 

• Data T ransfer 

• Connection Release 
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Local Management. This phase enables a DLS user to initialize a 
stream for use in communication and establish an identity with the DLS 
provider. 

Connection Establishment. This phase enables two DLS users to 
establish a data link connection between them to exchange data. One 
user (the calling DLS user) initiates the connection establishment 
procedures, while another user (the called DLS user) waits for incoming 
connect requests. The called DLS user is identified by an address 
associated with its stream. 

A called DLS user may either accept or deny a request for a data link 
connection. If the request is accepted, a connection is established 
between the DLS users and they enter the data transfer phase. 

For both the calling and called DLS users, only one connection my be 
established per stream. Thus, the stream is the communication endpoint 
for a data link connection. 

The called DLS user may choose to accept a connection on the stream 
where it received the connect request, or it may open a new stream to the 
DLS provider and accept the connection on this new, responding stream. 
By accepting the connection on a separate stream, the initial stream can 
be designated as a listening stream through which all connect requests 
will be processed. As each request arrives, a new stream (communication 
endpoint) can be opened to handle the connection, enabling subsequent 
requests to be queued on a single stream until they can be processed. 

Data Transfer. I n this phase, the DLS users are considered peers and 
may exchange data simultaneously in both directions over an established 
data link connection. Either DLS user may send data to its peer DLS 
user at any time. Data sent by a DLS user is guaranteed to be delivered 
to the remote user in the order in which it was sent. 

Connection Release. This phase enables either the DLS user, or the 
DLS provider, to break an established connection. The release procedure 
is considered abortive, so any data that has not reached the destination 
user when the connection is released may be discarded by the DLS 
provider. 
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Connectionless-mode Service 

The connectionless mode service does not use the connection 
establishment and release phases of the connection mode service. The 
local management phase is still required to initialize a stream. Once 
initialized, however, the connectionless data transfer phase is 
immediately entered. Becausethere is no established connection, 
however, the connectionless data transfer phase requires the DLS user to 
identify the destination of each data unit to be transferred. The 
destination DLS user is identified by the address associated with that 
user. 

DLPI Addressing 

Each user of DLPI must establish an identity to communicate with other 
data link users. This identity consists of two pieces. First, the DLS user 
must somehow identify the physical medium over which it will 
communicate. This is particularly evident on systems that are attached 
to multiple physical media. Second, the DLS user must register itself 
with the DLS provider so that the provider can deliver protocol data 
units destined for that user. Figure 1-2 illustrates the components of this 
identification approach, which are explained below. 

Data Link Addressing Components 


DLS Users 



Physical Attachment Identification 

The physical point of attachment (PPA in Figure 1-2) is the point at 
which a system attaches itself toa physical communications medium. All 
communication on that physical medium funnels through the PPA. On 
systems where a DLS provider supports morethan one physical medium, 
the DLS user must identify which medium it will communicate through. 
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A PPA is identified by a unique PPA identifier. For media that support 
physical layer multiplexing of multiple channels over a single physical 
medium (such as the B and D channels of I SDN), the PPA identifier must 
identify the specific channel over which communication will occur. 

Two styles of DLS provider are defined by DLPI, distinguished by the 
way they enable a DLS user to choose a particular PPA. The style 1 
provider assigns a PPA based on the major/mi nor devicethe DLS user 
opened. This style of provider is appropriate when few PPAs will be 
supported. 

If the number of PPAs a DLS provider will support is large, a style 2 
provider implementation is more suitable. The style 2 provider requires 
a DLS user to explicitly identify the desired PPA using a special attach 
service primitive. For a style 2 driver, the open(2) creates a stream 
between the DLS user and DLS provider, and the attach primitive then 
associates a particular PPA with that stream. The format of the PPA 
identifier is specific to the DLS provider. 

DLPI provides a mechanism to get and/or modify the physical address. 
The primitives to handle these functions are described in Chapter 2.The 
physical address value can be modified in a post-attached state. This 
modifies the value for all streams for that provider for a particular PPA. 
The physical address cannot be modified if even a single stream for that 
PPA is in the bound state. 

The DLS user uses the supported primitives DL_ATTACFI_REQ, 
DL_BIND_REQ, DL_ENABMULTI_REQ, and DL_PROMISCON_REQ 
to define a set of enabled physical and SAP address components on a per 
stream basis. It is invalid for a DLS provider to ever send upstream a 
data message for which the DLS user on that stream has not requested. 
The burden is on the provider to enforce the isolation of SAP and 
physical address space effects on a per-stream basis by any means that it 
chooses. 

HP PPA Format 

The PPA number which is passed in the DL_ATTACFI_REQ primitive 
should correspond to the network management ID (N MID) of the 
interface being attached to. The network management ID is obtainable 
in one of two ways: 1) the lanscan(lM) command, and 2) 
programmatically via the FIP_PPA_REQ primitive (see Chapter 2). 
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Data Link User Identification 

A data link user's identity is established by asscxiiating it with a data 
link service access point (DLSAP), which is the point through which the 
user will communicate with the data link provider. A DLSAP is identified 
by a DLSAP address. 

The DLSAP address identifies a particular data link service access point 
that is associated with a stream (communication endpoint). A bind 
service primitive enables a DLS user to either choose a specific DLSAP 
by specifying its address, or to determine the DLSAP associated with a 
stream by retrieving the bound DLSAP address. The DLSAP address can 
then be used by other DLS users to access a specific DLS user. The 
format of the DLSAP address is specific to the DLS provider. However, 
DLPI provides a mechanism for decomposing the DLSAP address into 
component pieces. The DLJ NFO_ACK primitive returns the length of 
the SAP component of the DLSAP address, along with the total length of 
the DLSAP address. 

HP's DLSAP Address Format (802.3, Ethernet, Token 
Ring, FDDI) 

Ethernet/I EEE802.3 and FDDI MAC addresses are presented in 
canonical format. Token Ring MAC addresses are presented in wire 
format. 

DLSAPs are what DLPI defines as an address through which the user 
will communicate to a Data Link Service (DLS) provider. The content of 
the DLSAP address will depend on the context in which it is used (i.e. 
which primitive is being processed or acknowledged). The basicformat of 
the DLSAP address is always the same. 

The basic DLSAP address format is: 

MAC address | SAP/Ethertype | SNAP (SAP = OxAA) | [RIF]| 

[ ] indicates that this information is optional. 

The three possible variations of the DLSAP address format based on the 
protocol value are: 

• 802.2 SAP format 

I DA/SA I DSAP/SSAP | [RIF, up to ISbytes] | 

• Ethertype format 

I DA/SA I TYPE I 
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• SNAP SAP format 

I DA/SA I OxAA I SNAP | [RIF, up to ISbytes] | 

HP's DLSAP Address Format for Fibre Channel 

The four possible formats for FibreChannel are: 

• 802.2 SAP format 

I N_Port_Id I Process Associator | FC_Type IDSAP/SSAP 

• 802.2 SAP without Process Associator format 

I N_Port_Id I FC_Type | DSAP/SSAP | 

• SNAP/SAP format 

IN_Port_IdI Process Associator|FC_Type|OxAA|SNAP Info| 

• SNAP/SAP without Process Associator format 

I N_Port_Id I FC_Type | OxAA | SNAP Info | 

Certain DLS providers require the capability of binding on multiple 
DLSAP addresses. This can be achieved through subsequent binding of 
DLSAP addresses. DLPI supports peer and hierarchical binding of 
DLSAPs. When the user requests peer addressing, the DLSAP specified 
in a subsequent bind may be used in lieu of the DLSAP bound in the 
DL_BI ND_REQ. This will allow for a choice to be made between a 
number of DLSAPs on a stream when determining traffic based on 
DLSAP values. An exampleof this would be to specify various ether_type 
values as DLSAPs. The DL_BI ND_REQ, for example, could be issued 
with an ether_type value of IP, and a subsequent bind could be issued 
with an ether_type value of ARP. The provider may now multiplex off the 
ether_type field and allow for either IP or ARP traffic to be sent up this 
stream. 

When the DLS user requests hierarchical binding, the subsequent bind 
will specify a DLSAP that will be used in addition to the DLSAP bound 
using a DL_BI ND_REQ. This will allow additional information to be 
specified, that will be used in a header or used for demultiplexing. An 
exampleof this would be to use hierarchical bind to specify the 
Organizational U nique I dentifier (OUI) to be used by SNAP. 

If a DLS provider supports peer subsequent bind operations, the first 
SAP that is bound is used as the source SAP when there is ambiguity. 
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DLPI supports the ability to asscxciate several streams with a single 
DLSAP, whereeach stream may be a unique data link connection 
endpoint. However, not all DLS providers can support such 
configurations because some DLS providers may have no mechanism 
beyond the DLSAP address for distinguishing multiple connections. In 
such cases, the provider will restrict the DLS user to one stream per 
DLSAP. 
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Promiscuous Mode Clarifications 

The following definitions are being defined for the various levels of 
promiscuous mode. 

DL_PROM I SC_PHYS—Before the STREAM has been bound (with the 
DL_BIND_REQ primitive), theDLPI user receives all traffic on the wire 
regardless of SAP or address. After the STREAM has been bound, the 
DLPI user receives all traffic on the wire that matches the protocol (s) the 
user has bound to on the promiscuous STREAM; this includes protocols 
bound with the DL_SU BS_BI N D_REQ. 

DL_PROM I SC_SAP—Before the STREAM has been bound (with the 
DL_BIND_REQ primitive), the DLPI user receives all traffic destined for 
this interface (physical addresses, broadcast addresses or bound 
multicast addresses) that matches any SAP enabled on that interface. 
After the STREAM has been bound, the DLPI user receives only those 
packets originally destined for the interface that match one of the 
protocol(s) bound on the promiscuous STREAM. 


NOTE The Series 700 core and El SA LAN andlOOVG drivers are currently the 

only hardware supporting promiscuous mode which is known to have a 
MULTICAST_ALL command. This command allows the chip to receive 
all packets with the group bit set. The other drivers will require that the 
hardware be in full promiscuous mode and then filter on the group bit in 
the driver. 


DL_PROM I SC_MULTI—Before the STREAM has been bound (with the 
DL_BIND_REQ primitive), the DLPI user receives all multicast packets 
on the wire regardless of the SAP. After the STREAM has been bound, 
the DLPI user receives all multicast packets that match one of the 
protocol(s) bound on the promiscuous STREAM. 


NOTE Each LAN interfacecurrently allows only one stream to enable the 

promiscuous mode service. This restriction will be removed with a future 
release of theDLPI provider. 
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DLPI Services 

The various features of the DLPI interface are defined in terms of the 
services provided by theDLS provider and the individual primitives that 
may flow between the DLS user and DLS provider. 

HP DLPI supportstwoof the three modes of service: connection and 
connectionless. HP DLPI does not support acknowledged connectionless 
service. The connection mode is circuit-oriented and enables data to be 
transferred over an established connection in a sequenced manner. The 
connectionless mode is message-oriented and supports data transfer in 
self-contained units with no logical relationship required between units. 
DLPI also includes a set of local management functions that apply to all 
modes of service. 

DLPI supports the XID and TEST services that appear in the following 
table. The DLS user can issue an XID or TEST request tothe DLS 
provider. The provider will transmit an XID or TEST frame to the peer 
DLS provider. On receiving a response, the DLS provider sends a 
confirmation primitive to the DLS user. On receiving an XID or TEST 
frame from the peer DLS provider, the local DLS provider sends up an 
XID or TEST indication primitive to the DLS user. The user must 
respond with an XID or TEST response frame to the provider. 

I n addition, raw mode service is now supported. Raw mode allows the 
DLS user to send and receive packets with complete LLC and MAC 
headers. 

Table 1-1 provides information about the DLPI services that are 
described in the following sections. 
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Table 1-1 Cross-Reference of DLS Services and Primitives 


Phase of 
Communication 

Service 

Primitives 

Lcxial Management 

I nformation 

Report! ng 

DL INFO REO 

DL INFO ACK 

DL ERROR ACK 

DL HP PPA REO 

DL_HP_PPA_ACK 


Attach 

DL ATTACH REO 

DL DETACH REO 

DL OK ACK 

DL_ERROR_ACK 


Bind 

DL BIND REO 

DL BIND ACK 

DL SUBS BIND REO 

DL SUBS BIND ACK 

DL UNBIND REO 

DL SUBS UNBIND REO 

DL OK ACK 

DL_ERROR_ACK 


Other 

DL ENABMULTI REO 

DL DISABMULTI REO 

DL PROM I SCON REO 

DL PROMISCOFF REO 

DL OK ACK 

DL ERROR ACK 

DL HP MULTICAST LIST REO 

DL HP MULTICAST LIST ACK 
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Phase of 
Communication 

Service 

Primitives 

Connection 

Establishment 

Connection 

Establishment 

DL CONNECT REQ 

DL CONNECT IND 

DL CONNECT RES 

DL CONNECT CON 

DL DISCONNECT REO 

DL DISCONNECT IND 

DL TOKEN REO 

DL TOKEN ACK 

DL OK ACK 

DL_ERROR_ACK 

Connection-mode 

Data T ransfer 

Data T ransfer 

DL DATA REO 

DL_DATAJND 


Reset 

DL RESET REO 

DL RESET IND 

DL RESET RES 

DL RESET CON 

DL OK ACK 

DL_ERROR_ACK 

Connection Release 

Connection Release 

DL DISCONNECT REO 

DL DISCONNECT IND 

DL OK ACK 

DL_ERROR_ACK 

C on nect i on I ess-mode 
Data Transfer 

Data T ransfer 

DL UNITDATA REO 
DL_UNITDATAJND 


Error Reporting 

DLUDERRORJND 
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Phase of 
Communication 

Service 

Primitives 

Raw Mode Data 

T ransfer 


DL HP RAWDATA REQ 

DL_H P_RAWDATA_I N D 

XID and TEST 

XI D 

DL XI D REQ 

DL XID IND 

DL XID RES 

DLXIDCON 


TEST 

DL TEST REQ 

DL TEST IND 

DL TEST RES 

DL TEST CQN 


Local Management Services 

The Icxial management services apply to the connection and 
connectionless modes of communication. These services, which fall 
outside the scope of standards specification, define the method for 
initializing a stream that is connected to a DLS provider. DLS provider 
information reporting services a re a I so supported by local management 
facilities. 

Information Reporting Service 

This service provides information about the DLPI stream to the DLS 
user. The message DL_I NFO_REQ requests the DLS provider to return 
operating information about the stream. The DLS provider returns the 
information in a DL_INFO_ACK message as shown in Figure 1-3. 

Figure 1-3 Message Flow: Information Reporting 


DLJNFO 

request 

DL INFO 



acknowledge 
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Figure 1-4 


Figure 1-5 


Attach Service 

The attach service assigns a physical point of attachment (PPA) to a 
stream. This service is required for style 2 DLS providers to specify the 
physical medium over which communications will occur. The DLS 
provider indicates success with a DL_OK_ACK message and failure with 
a DL_ERROR_ACK message. The normal message sequence is 
illustrated in Figure 1-4. 

Message Flow: Attaching a Stream to a Physical Line 


DL ATTACH 


request 



DL OK 



acknowledge 


A PPA may be disassociated with a stream using the 
DL_DETACH_REQ. The normal message sequence is illustrated in 
Figure 1-5. 

Message Flow: Detaching a Stream to a Physical Line 


DL DETACH 


request 
DL OK 



acknowledge 


Bind Service 

The bind service associates a data link service access point (DLSAP) with 
a stream. The DLSAP is identified by a DLSAP address. 

DL_BI ND_REQ requests that the DLS provider bind a DLSAP to a 
stream. 11 also notifies the DLS provider to make the stream active with 
respect to the DLSAP for processing connectionless data transfer and 
connection establishment requests. DL_SUBS_BI ND_REQ provides the 
added capability on binding on multiple DLSAP addresses. 
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Binding 

The following protocol values are currently supported by the DLPI 
driver: 

• IEEE802.2 SAPS 

• ethernet types 

• SNAP 

Valid IEEE802.2 SAPS include even numbers from 0-255, excluding 
reserved SAPS (see the sect! on "Reserved I EEESAPS/Ethertypes"). Valid 
ethernet types range from 0x600 to OxF F F F, excl udi ng reserved 
ethertypes (see the section "Reserved I EEESAPS/Ethertypes"). The 
SNAP protocol values contain three bytes of organization ID pi us two 
bytes of additional data. If the first three bytes are 0, the following two 
bytes are an ethernet type with valid values from OxO-OxFFFF. If the 
first three bytes are non-zero, the following two bytes are organization 
specific with valid values from OxO-OxFFFF. 

I EEE802.2 SAPS and ethernet types are bound to the driver via the 
DL_BIND_REQ or the DL_SU BS_BI N D_REQ (DL_PEER_BI ND class 
only). SNAP protocol values can be logged in two ways. The first method 
requires you to first bind the SNAP SAP OxAA via the DL_BI ND_REQ 
primitive. You then must issue a DL_SUBS_BI ND_REQ (must be 
DL_FII ERARCFIICAL_BI ND class) with the five bytes of SNAP data. 
The second method requires you to bind any non-SNAP protocol value 
via the DL_BI ND_REQ primitive and then issue a 
DL_SU B S_B IN D_RE Q (must be D L_P E E R_B IN D cl ass) wi t h si x bytes 
of data. The first byte must bethe SNAP SAP OxAA followed by five 
bytes of SNAP data. 

Reserved IEEE SAPS/E thertypes 

Refer to the IETF RFC 1010 "Assigned Numbers." 

The DLS provider indicates success with a DL_BI ND_ACK or a 
DL_SUBS_BI ND_ACK message and failure with a DL_ERROR_ACK 
message. 

The normal flow of messages is illustrated in Figure 1-6. 
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Figure 1-6 


Figure 1-7 


Message Flow: Binding a Stream to a DLSAP 


DL_BIND 

request 

DL BIND 



acknowledge 


DL_SUBS_BIND 
request 

DL_SUBS_BIND 

acknowledge 



DL_UNBI ND_REQ requests the DLS provider to unbind all DLSAPs 
from a stream. The DL_UNBI ND_REQ also unbinds all the 
subsequently bound DLSAPs that have not been unbound. The DLS 
provider indicates success with a DL_OK_ACK message and failure with 
a DL_ERROR_ACK message. 

DL_SUBS_UNBI ND_REQ requests the DLS provider to unbind the 
subsequently bound DLSAP. The DLS provider indicates success with a 
DL_OK_ACK message and failure with a DL_ERROR_ACK message, as 
shown in Figure 1-7. 

Message Flow: Unbinding a Stream from a DLSAP 


DL UNBIND 


request 
DL OK 



acknowledge 


DL SUBS UNBIND 


request 
DL SUBS OK 



acknowledge 


DL_ENABMULTI_REQ requests the DLS provider to enable specific 
multicast addresses on a per stream basis. The provider indicates 
success with a DL_OK_ACK message and failure with a 
DL ERROR ACK message. 

The normal message sequence is illustrated in Figure 1-8. 
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Figure 1-9 


Figure 1-10 
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Message Flow: Enabling a Specific Multicast Address on a 
Stream 


DL_ENABMULTI 

request 

DL_OK 

acknowledge 



DL_DISABMULTI_REQ requests the DLS provider to disable specific 
multicast addresses on a per stream basis. The provider indicates 
success with a DL_OK_ACK message and failure with a 
DL_ERROR_ACK message. 

The normal message sequence is illustrated in Figure 1-9. 

Message Flow: Disabling a Specific Multicast Address on a 
Stream 


DL DISABMULTI 


request 
DL OK 



acknowledge 


DL_PROMISCON_REQ requests the DLS provider to enable 
promiscuous mode on a per stream basis, either at the physical level of at 
the SAP level. The provider indicates success with a DL_OK_ACK 
message and failure with a DL_ERROR_ACK message. 

The normal message sequence is illustrated in Figure 1-10. 

Message Flow: Enabling Promiscuous Mode on a Stream 


DL PROMISCON 


request 


DL OK 



acknowledge 
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Figure 1-11 


DL_PROMISCOFF_REQ requests the DLS provider to disable 
promiscuous mode on a per stream basis, either at the physical level of at 
the SAP level. The provider indicates success with a DL_OK_ACK 
message and failure with a DL_ERROR_ACK message. 

The normal message sequence is illustrated in Figure 1-11. 

Message Flow: Disabling Promiscuous Mode on a Stream 


DL PROMISCOFF 


request 
DL OK 



acknowledge 


Connection-mode Services 

The connection-mode services enable a DLS user to establish a data link 
connection, transfer data over that connection, reset the link, and release 
the connection when the conversation has terminated. 

Connection Establishment Service 

The connection establishment service establishes a data link connection 
between a local DLS user and a remote DLS user for the purpose of 
sending data. Only one data link connection is allowed on each stream. 

Normal Connection Establishment, in the connection 
establishment model, the calling DLS user initiates connection 
establishment, whilethe called DLS user waits for incoming requests. 
DL_CONNECT_REQ requests that the DLS provider establish a 
connection. DL_CONNECT_l ND informs the called DLS user of the 
request, which may be accepted using DL_CONNECT_RES. 
DL_CONNECT_CON informs the calling DLS user that the connection 
has been established. 

The normal sequence of messages is illustrated in Figure 1-12. 
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Figure 1-12 


Message Flow: Successful Connection Establishment 


DL CONNECT 


request 




DL_CONNECT 

indication 


DL_CONNECT 

confirm 



< 



DL_CONNECT 

response 

DL_OK 

acknowledge 


Once the connection is established, theDLS users may exchange user 
data using DL_DATA_REQ and DL_DATA_I ND. 

The DLS user may accept an incoming connect request on either the 
stream where the connect indication arrived or at an alternate, 
responding stream. The responding stream is indicated by a token in the 
DL_CONNECT_RES. This token is a value associated with the 
responding stream and is obtained by issuing a DL_TOKEN_REQ on 
that stream. The DLS provider responds to this request by generating a 
token for the stream and returning it to the DLS user in a 
DL TOKEN ACK. 


Connection Handoff 

Connections may be established on a stream other than that which 
received the DL_CON N E CT_I ND by passing a non-zero dl_resp_token in 
the DL_CON N ECT_RE S. The dl_resp_token val ue is obtai ned by doi ng a 
DL_TOKEN_RE0 on the stream the connection is being passed to (the 
data stream). The DL_CONNECT_RES is done on the stream which 
received the DL_CON N ECTJ N D (the control stream). Both the control 
and data streams must be bound on the same local SAP. After the 
DL_CONNECT_RES, the control stream will be left in the 
I NCON_PEND state if there are more outstanding connect indications; 
otherwise, it will be left in the IDLE state. The data stream will be in the 
DATAXFER state. 

The normal sequence of messages for obtaining a token is illustrated in 
Figure 1-13. 
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Figure 1-13 


Message Flow: Token Retrieval 


DL TOKEN 


request 

DL_TOKEN 

acknowledge 



Figure 1-14 


In the typical connection establishment scenario, the called DLS user 
processes one connect indication at a time, accepting the connection on 
another stream. Once the user responds to the current connect 
indication, the next connect indication (if any) can be processed. DLPI 
also enables the called DLS user to multi-thread incoming connect 
indications. The user can receive multiple connect indications before 
responding to any of them. This enables the DLS user to establish 
priority schemes on incoming connect requests. 

Connection Establishment Rejection. I n certain situations, the 
connection establishment request cannot be completed. The following 
describes the occasions under which DL_DISCONNECT_REQ and 
DL_DI SCONNECTJ ND primitives will flow during connection 
establishment, causing the connect request to be aborted. 

Figure 1-14 illustrates the situation where the called DLS user chooses 
to reject the connect request by issuing DL_DI SCON NECT_REQ instead 
of DL_CONNECT_RES. 


Message Flow: Called DLS User Rejection of Connection 
E stabi i sh ment Attempt 


DL CONNECT 




DL_CONNECT 

indication 

DL_DISCONNECT 

request 

DL_OK 

acknowiedge 


Figure 1-15 illustrates the situation where the DLS provider rejects a 
connect request for lack of resources or other reasons. The DLS provider 
sends DL_DI SCON N E CT_I N D i n response to DL_CON N E CT_RE 0- 
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Figure 1-16 


Figure 1-17 
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Message Flow: DLS Provider Rejection of a Connection 
E stabi i sh ment Attempt 


DL_CONNECT 

request 



DL_DISCONNECT 

indication 



Figure 1-16 through Figure 1-18 illustrate the situation where the 
calling DLS user chooses to abort a previous connection attempt. The 
DLS user issues DL_DISCONNECT_REQ at some point following a 
DL_CONNECT_REQ. The resulting sequence of primitives depends on 
the relative timing of the primitives involved, as defined in the following 
time sequence diagrams. 


Message Flow: Both Primitives are Destroyed by Provider 


DL_CONNECT 
request 

DL_DISCONNECT 
request 

DL_OK 
acknowledge 


Message Flow: DL DISCONNECT Indication Arrives before 
DL CONNECT Response is Sent 


DL CONNECT 


request 



DL DISCONNECT 


request 

DL_OK 

acknowledge 




DL_CONNECT 

indication 


>• 



DL_DISCONNECT 

indication 
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Figure 1-18 


Message Flow: DL DISCONNECT Indication Arrives after 
DL CONNECT Response is Sent 


DL_CONNECT 

request 



DL_DISCONNECT 

request 

DL OK 



acknowledge 



DL_CONNECT 

indication 



DL_CONNECT 

response 

DL OK 



aoknowledge 

DL_DISCONNECT 

indication 


Figure 1-19 


Data Transfer Service 

The connection-mcxde data transfer service provides for the exchange of 
user data in either direction or in both directions simultaneously 
between DLS users. Data is transmitted in logical groups called data 
link service data units (DLSDUs). The DLS provider preserves both the 
sequence and boundaries of DLSDUs as they are transmitted. 

Normal data transfer is neither acknowledged nor confirmed. It is up to 
the DLS users, if they so choose, to implement a confirmation protocol. 

Each DL_DATA_REQ primitive conveys a DLSDU from the local DLS 
user to the DLS provider. Similarly, each DL_DATA_IND primitive 
conveys a DLSDU from the DLS provider to the remote DLS user. The 
normal flow of messages is illustrated in Figure 1-19. 


Message Flow: Normal Data Transfer 


DL_DATA 

request 




DL_DATA 

indication 
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Figure 1-20 


Figure 1-21 


Connection Release Service 

The connection release service provides for the DLS users or the DLS 
provider to initiate the connection release. Connection release is an 
abortive operation and any data in transit (has not been delivered to the 
DLS user) may be discarded. 

DL_DISCONNECT_REQ requests that a connection be released. 

DL_DI SCONNECTJ ND informs the DLS user that a connection has 
been released. Normally, one DLS user requests disconnection and the 
DLS provider issues an indication of the ensuing release to the other 
DLS user, as illustrated by the message flow in Figure 1-20. 


Message Flow: DLS User-Invoked Connection Release 


DL DISCONNECT 


request 
DL OK 



acknowledge 



DL_DISCONNECT 

indication 


Figure 1-21 illustrates that when two DLS users independently invoke 
the connection release service, neither received a 
DL_DISCONNECTJND. 

Message Flow: Simultaneous DLS User Invoked Connection 
Release 


DL_DISCONNECT 
request 

DL_OK 
acknowledge 

Figure 1-22 illustrates that when the DLS provider and the local DLS 
user simultaneously invoke the connection release service, the remote 
DLS user receives a DL_DI SCONNECTJ ND. 


DL_DISCONNECT 
request 


DL_OK 

acknowledge 
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Figure 1-22 


Message Flow: Simultaneous DLS User & DLS Provider Invoked 
Connection Release 


DL DISCONNECT 


request 
DL OK 



acknowledge 



DL_DISCONNECT 

indication 


Reset Service 

The reset service may be used by the DLS user to resynchronize the use 
of a data link connection, or by the DLS provider to report detected loss 
of data unrecoverable within the data link service. 

I nvocations of the reset service will unblock the flow of DLSDUs if the 
data link connection id congested; DLSDUs may be discarded by the DLS 
provider. The DLS user or users that did not invoke the reset will be 
notified that a reset has occurred. A reset may require a recovery 
procedure to be performed by the DLS users. 

The interaction between each DLS user and the DLS provider will be one 
of the following: 

• a DL_RESET_REQ from the DLS user, followed by a 
DL_RESET_CON from the DLS provider, 

• a DL_RESET_I ND from the DLS provider, followed by a 
DL_RESET_RES from the DLS user. 

The DL_RESET_REQ acts as a synchronization mark in the stream of 
DLSDUs that are transmitted by the issuing DLS user; the 
DL_RESET_I ND acts as a synchronization mark in the stream of 
DLSDUs that are received by the peer DLS user. Similarly, the 
DL_RESET_RES acts as a synchronization mark in the stream of 
DLSDUsthat are transmitted by the responding DLS user; the 
DL_RESET_CON acts as a synchronization mark in the stream of 
DLSDUs that are received by the DLS user which originally issued the 
reset. 

The resynchronizing properties of the reset service are: 

• NoDLSDU transmitted by the DLS user before the synchronization 
mark in that transmitted stream will be delivered to the other DLS 
user after the synchronization mark in that received stream. 
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Figure 1-23 


Figure 1-24 


• TheDLS provider will discard all DLSDUs submitted before the 
issuing of the DL_RESET_REQ that have not been delivered to the 
peer DLS user when the DLS provider issues the DL_RESET_I ND. 

• TheDLS provider will discard all DLSDUs submitted before the 
issuing of the DL_RESET_RES that have not been delivered to the 
initiator of the DL_RESET_REQ when the DLS provider issues the 
DLRESETCON. 

• NoDLSDU transmitted by a DLS user after the synchronization 
mark in that transmitted stream will be delivered to the other DLS 
user before the synchronization mark in that received stream. 

The complete message flow depends on the origin of the reset, which may 
be the DLS provider or either DLS user. Figure 1-23 illustrates the 
message flow for a reset invoked by one DLS user. 


Message Flow: DLS User-Invoked Connection Reset 


DL_RESET 

request 




DL_RESET 

indication 


DL_RESET 

confirm 



DL_RESET 

response 

DL_OK 

acknowledge 


Figure 1-24 illustrates the message flow for a reset invoked by both DLS 
users simultaneously. 

Message Flow: Simultaneous DLS User-Invoked Connection 
Reset 


DL RESET 


request 



DL_RESET 

confirm 




DL_RESET 

request 



DL_RESET 

confirm 


Figure 1-25 illustrates the message flow for a reset invoked by the DLS 
provider. 
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Figure 1-25 


Figure 1-26 


Message Flow: DLS Provider-Invoked Connection Reset 


DL_RESET 

indication 



DL_RESET 

response 

DL_OK 

acknowledge 




DL_RESET 

indication 



DL_RESET 

response 

DL_OK 

acknowledge 


Figure 1-26 illustrates the message flow for a reset invoked 
simultaneously by one DLS user and the DLS provider. 

Message Flow: Simultaneous DLS User & DLS Provider-Invoked 
Connection Reset 


DL_RESET 

request 



DL_RESET 

confirm 




DL_RESET 

indication 



DL_RESET 

response 

DL_OK 

acknowledge 


Connectionless-mode Services 

The connectionless-mode services enable a DLS user to transfer units of 
data to peer DLS users without incurring the overhead of establishing 
and releasing a connection. The connectionless service does not, however, 
guarantee reliable delivery of data units between peer DLS users (e.g. 
lack of flow control may cause buffer resource shortages that result in 
data being discarded). 

Once a stream has been initialized via the local management services, it 
may be used to send and retrieve connectionless data units. 

Connectionless Data Transfer 

The connectionless data transfer service provides for the exchange of 
user data (DLSDUs) in either direction or in both directions 
simultaneously without having to establish a data link connection. Data 
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Figure 1-27 


Figure 1-28 
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transfer is neither acknowledged nor confirmed, and there is no 
end-to-end flow control provided. As such, the connectionless data 
transfer service cannot guarantee reliable delivery of data. However a 
specific DLS provider can provide assurancethat messages will not be 
lost, duplicated, or reordered. 

DL_UNITDATA_REQ conveys one DLSDU to the DLS provider. 
DL_UNITDATA_I ND conveys one DLSDU to the DLS user. The normal 
flow of messages is illustrated in Figure 1-27. 


Message Flow: Connectionless Data Transfer 


DL UNITDATA 


request 



► 



DL_UNITDATA 

indication 


Error Reporting Service 

The connectionless-mode error reporting service may be used to notify a 
DLS user that a previously sent data unit either produced an error or 
could not be delivered. This service does not, however, guarantee that an 
error indication will be issued for every undeliverable data unit. 

Connectionless-Mode Error Reporting 

DL_UDERROR 

indication 


Raw-mode Services 

The raw-mode services enable a DLS user to transfer packets containing 
complete MAC and LLC headers to a peer DLS user. The raw-mode 
service does not guarantee reliable delivery of data units between peer 
DLS users (e.g. lack of flow control may cause buffer resource shortages 
that result in data being discarded). 

The DLS user requests the raw-mode services by setting the service 
mode in the DL_BI ND_REQ to DL_H P_RAWDLS. 
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Figure 1-29 


Figure 1-30 


Raw-mode Data Transfer 

The raw-mcxde data transfer service provides the same service as the 
connectionless data transfer service. The only difference is that the raw¬ 
mode DLS user builds the complete MAC and LLC headers prior to data 
transfer, whereas the connectionless-mode DLS user merely specifies the 
peer DLS user and the DLS provider then builds the complete MAC and 
LLC headers before transferring the packet. 

The DL_H P_RAWDATA_REQ conveys one DLSDU to the DLS provider. 
The DL_H P_RAWDATA_I ND conveys one DLSDU to the DLS user. The 
normal flow of messages is illustrated in Figure 1-29. 


Message Flow: Raw Data Transfer 


DL HP RAWDATA 


request 



>• 



DL_HP_RAWDATA 

indication 


Error Reporting Service 

The raw-mode error reporting service provides the same services as the 
connect ion I ess-mode error reporting services. However, the 
DL_ERROR_ACK primitive is used in place of the DL_UDERROR 
primitive to report all error conditions in raw-mode. 

Raw-Mode Error Reporting 


DL_ERROR_ACK 
indication 


XID and TE ST Service 

The XID and TEST service enables the DLS user to issue an XID or 
TEST request tothe DLS provider. On receiving a response for theXI D 
or TEST frame transmitted to the peer DLS provider, the DLS provider 
sends up an XIS orTEST confirmation primitive to the DLS user. On 
receiving an XID or TEST frame from the peer DLS provider, the local 
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Figure 1-31 


DLS provider sends up an XID or TEST indication respectively to the 
DLS user. The DLS user must respond with an XID or TEST response 
primitive. 

If the DLS user requested automatic handling of the XID or TEST 
response, at bind time, the DLS provider will send up an error 
acknowledgment on receiving an XID or TEST request. Also, no 
indications will degenerated to the DLS user on receiving XID or TEST 
frames from the remote side. 


XID and TEST Packet Handling 

XID and TEST packets are handled differently on connection oriented 
streams than they are on connectionless streams. On connectionless 
streams, XID and TEST packets may be sent and received by any stream 
at any time after binding. On connection oriented streams, XID and 
TEST packets may be sent and recei ved at any time after bindi ng by 
streams specifying a non- zerodl_max_conind in the DL_BI ND_REQ. 
Connection oriented streams which specify a zerodl_max_conind in the 
DL_BI ND_REO will only receiveXI D and TEST packets after a 
connection has been established. 

LLC Type 2 monitors XID packets sent and received on connection 
oriented streams. If the stream has a connection established, LLC Type 2 
will set the local and remote receive window sizes to those specified in 
the XID packets. 

The normal flow of message is illustrated in Figure 1-31 and Figure 1-32. 


Message Flow: XID Service 


DL_XID 

request 




DL_XID 

indication 


DL_XID 

confirm 




DL_XID 

response 
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Figure 1-32 


Message Flow: Test Service 


DL TEST 


request 




DL_TEST 

indication 


DL_TEST 

confirm 






DL_TEST 

response 


An Example 

To summarize, Figure 1-33 is an example that illustrates the primitives 
that flow during a complete, connection-mode sequence between stream 
open and stream close. 
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Message Flow: A Connection-Mode Example 


DL_ATTACH 
request 

DL_OK 
acknowledge 

DL_BIND 
request 

DL_BIND 

acknowledge 

DL_CONNECT- 

request 


DL_CONNECT 
confirm 

DL_DATA 
request 


DL_DATA 
indication 

DL_DISCONNECT 
request 

DL_OK 
acknowledge 

DL_UNBIND 
request 

DL_OK 
acknowledge 

DL_DETACH 
request 

DL_OK 
acknowledge 






.DL_ATTACH 
request 

DL_OK 

acknowledge 

DL_BIND 
request 

DL_BIND 
aoknowledge 

DL_CONNECT 

indication 

DL_CONNECT 

response 

DL_OK 

acknowledge 

DL_DATA 

indication 

DL_DATA 

request 


.DL_DISCONNECT 

indioation 

DL_UNBIND 

request 

DL_OK 

acknowledge 

DL_DETACH 

request 

DL_OK 

acknowledge 
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The kernel-level I nterface to the data link layer defines a 
STREAM S-based message interface between the provider of the data 
link service (DLS provider) and the consumer of the data link service 
(DLS user). STREAMS provides the mechanism in which DLPI 
primitives may be passed between the DLS user and DLS provider. 

Before DLPI primitives can be passed between the DLS user and the 
DLS provider, the DLS user must establish a stream to the DLS provider 
using open(2). The DLS provider must therefore be configured as a 
STREAMS driver. When interactions between the DLS user and DLS 
provider have completed, the stream may be closed. 

The STREAMS messages used to transport data link service primitives 
across the interface have one of the following formats: 

• One M_PROTO message block followed by zero or more M_DATA 
blocks. The M_PROTO message block contains the data link layer 
service primitive type and all relevant parameters associated with 
the primitive. The M_DATA block(s) contain any DLS user data that 
might be associated with the service primitive. 

• OneM_PCPROTO message block containing the data link layer 
service primitive type and all relevant parameters associated with 
the service primitive. 

• One or more M_DATA message blocks conveying user data. 

The fol lowing sections describe the format of the supported primitives. 
The primitives are grouped into four categories: 

• Local Management Service Primitives 

• Connect ion I ess-mode Service Primitives 

• Connection-mode Service Primitives 

• Primitives to handle XID and TEST operations 

All of the DLPI extensions listed in this chapter are defined in 

<sys/dlpi_ext.h> and <sys/dlpi.h>. 
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Local Management Primitives 

This section describes the local management service primitives. These 
primitives support the information reporting, Attach and Bind. Once a 
stream has been opened by a DLS user, these primitives initialize the 
stream, preparing it for use. 

P PA I n iti al i zati on/De-i n iti al i zati on 

The PPA associated with each stream must be initialized before the DLS 
provider can transfer data over the medium. The initialization and 
de-initialization of the PPA is a network management issue, but DLPI 
must address the issue because of the impact such actions will have on a 
DLS user. More specifically, DLPI requires the DLS provider to initialize 
the PPA associated with a stream at some point before it completes the 
processing of the DL_BI ND_REQ. Guidelines for initialization and 
de-initialization of a PPA by a DLS provider are presented here. 

A DLS provider may initialize a PPA using the following methods: 

• pre-initialized by some network management mechanism before the 
DL_BI ND_REQ is received; or 

• automatic initialization on receipt of a DL_BI ND_REQ or 
DLATTACHREQ. 

A specific DLS provider may support either of these methods, or possibly 
some combi nation of the two, but the method implemented has no impact 
on the DLS user. From the DLS user's viewpoint, the PPA is guaranteed 
to be initialized on receipt of a DL_BI ND_ACK. For automatic 
initialization, this implies that the DL_BI ND_ACK may not be issued 
until the initialization has completed. 

If pre-initialization has not been performed and/or automatic 
initialization fails, the DLS provider will fail the DL_BI ND_REQ. Two 
errors, DL_I NITFAI LED and DL_NOTI NIT, may be returned in the 
DL_ERROR_ACK response to a DL_BIND_REQ if PPA initialization 
fails. DL_I NITFAI LED is returned when a DLS provider supports 
automatic PPA initialization, but the initialization attempt failed. 
DL_NOTI NIT is returned when the DLS provider requires 
pre-initialization, but the PPA is not initialized beforethe 
DL_BIND_REQ is received. 
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A DLS provider may handle PPA de-initialization using the foil owing 
methods: 

• automatic de-initialization upon receipt of the final 
DL_DETACH_REQ (for style 2 providers) or DL_UNBI ND_REQ (for 
style 1 providers), or upon closing of the last stream associated with 
the PPA; 

• automatic de-initialization after expiration of a timer following the 
last DL_DETACH_REQ, DL_UNBI ND_REQ, or close as appropriate; 
or 

• no automatic de-initialization; administrative intervention is 
required to de-initializethe PPA at some point after it is no longer 
being accessed. 

A specific DLS provider may support any of these methods, or possibly 
some combination of them, but the method implemented has no impact 
on the DLS user. From the DLS user's viewpoint, the PPA is guaranteed 
to be initialized and availablefor transmission until it closes or unbinds 
the stream associated with the PPA. 

DLS provider-specific addendum documentation should describethe 
method chosen for PPA initialization and de-initialization. 

DL_HP_PPA_REQ 

This primitive is used to obtain a list of all the valid PPAs currently 
installed in the system. 

This message consists of one M_PCPROTO message block which 
contains the following structure. 

Format 

typedef struct { 

u_long dl_primitive; 

) dl_hp_ppa_req_t; 

Parameters 

dl_primitive 

DL_HPPPAREQ 

State 
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The message is valid in any State in which a Icxal acknowledgment is not 
pending, as described in Appendix B, Allowable Sequence of DLPI 
Primitives, of the DLPI 2.0 specification. 

New State 

The resulting state is unchanged. 

Response 

The DLPI driver responds to this request with a DL_H P_PPA_ACK. 

DL_HP_PPA_ACK 

This primitive is sent in response to a DL_HP_PPA_REQ; it conveys 
information on each valid PPA currently installed in the system. 

This message consists of one M_PCPROTO message block which 
contains the following structure and information. 

Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_length; 

u_long dl_count; 

u_long dl_offset; 

) dl_hp_ppa_ack_t; 

Parameters 

dl_primitive 

DL_H P_PPA_ACK 
dijength 

length of the data area following the DL_HP_PPA_ACK primitive. 
The data area is formatted as one or more dl_hp_ppa_i nfo_t 
structures (see below). 

dl_count 

number of PPAs in the list. 
dl_offset 

offset from the beginning of the M_PCPROTO block where the 
dl_hp_ppa_info_t information begins. 
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.nfo area in 

DL_HP_PPA_ACK * 

/ 

typedef struct { 


u_long 

dl_next_offset; 


u_long 

dl_ppa; 


u_char 

dl_hw_path [10 0] 

; 

u_long 

dl_mac_type; 


u_char 

dl_phys_addr[2 0 

]; 

u_long 

dl_addr_length; 


u_long 

d l_m j r_n um; 


u_char 

dl_name[64] 


u_long 

dl_instance_num 

u_long 

dl_mtu; 


u_long 

dl_hdw_state; 


u_char 

dl_module_id_l[ 

64 

u_char 

dl_module_id_2[ 

64 

u_char 

dl_arpmod_name[ 

64 

u_char 

dl_nmid; 


u_long 

dl_reservedl; 


u_long 

dl_reserved2; 



} cil_hp_ppa_info_t; 

dl next offset 


offset of next ppa info structure from start of info area. 
dl_ppa 

PPA #assigned to LAN interface. 
dl_hw_path 

hardware path of LAN interface. 
dl_mac_type 

MAC type of LAN interface. 
dl_phys_addr 
station address. 
dl_addr_length 

length of station address. 
dl_mjr_num 

major number of interface driver, 
dl name 


name of driver, 
dl instance num 


instance number of device. 
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dl_mtu 

MTU 

dl_hdw_state 
hardware state 
dl_m<xlule_id_l 

default module ID name for the stream. The default name is "Ian." 
This value is used as the interface name when executing the 
ifconfig command. 

dl_module_id_2 

optional module ID name for streams that support multiple 
encapsulation types. If the user is attached to a stream that supports 
ETHER and IEEE8023, then this name is set to "snap." Otherwise, 
the field is set to NULL. This value is used as the interface name 
when executing the ifconfig command. 

dl_arpmod_name 

identifies the ARP helper module for the network interface. If the 
driver does not have an ARP helper, this field will be NULL. 

dl_nmid 

identifies the network management ID value for a specific interface. 
dl_reserved[l,2] 
reserved fields 

State 

The message is valid in any State in response to a DL_PPA_REQ. 

New State 

The resulting state is unchanged. 

DLJNFO_REQ 

Requests information of the DLS provider about the DLPI stream. This 
information includes a set of provider-specific parameters, as well as the 
current state of the i nterface. 
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The message consists of one M_PCPROTO message block, which 
contains the following structure. 

Format 

typedef struct { 

ulong dl_primitive; 

} dl_info_req_t; 

Parameters 

cll_primitive 

DLJNFO_REQ 

State 

The message is valid in any state in which a local acknowledgment is not 
pending, as described in Appendix B, Allowable Sequence of DLPI 
Primitives, of the DLPI 2.0 specification. 

New State 

The resulting state is unchanged. 

DLJNFO_ACK 

This message is sent in response to DL_I NFO_REQ; it conveys 
information about the DLPI stream to the DLS user. 

This message consists of one M_PCPROTO message block, which 
contains the following structure. 

Format 


struct { 


ulong 

dl_primitve; 

ulong 

dl_max_sdu; 

ulong 

dl_min_sdu; 

ulong 

dl_addr_length; 

ulong 

dl_mac_type; 

ulong 

dl_reserved; 

ulong 

dl_current_state; 

ulong 

dl_sap_length; 

ulong 

dl_service_mode; 

ulong 

dl_qos_length; 

ulong 

dl_qos_offset; 

ulong 

dl_qos_range_length; 

ulong 

dl_provider_style; 

ulong 

dl_addr_o f f s et; 

ulong 

dl_version; 

ulong 

dl_brdcst_addr_length; 
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ulong dl_brdcst_addr_offset; 

ullong dl_growth; 

} dl_info_ack_t; 

Parameters 

dl_primitive 

DLJNFO_ACK 

dl_max_sdu 

maximum number of bytes that may be transmitted in a data link 
service data unit (DLSDU). This value must be a positive integer that 
is greater than or equal to the value of dl_min_sdu. 

dl_min_sdu 

minimum number of bytes that may be transmitted in a DLSDU. The 
value is never less than one. 

dl_addr_length 

length, in bytes, of the provider's DLSAP address. 
dl_mac_type 

type of medium supported. Possible values: 

DL_CSMACD 

Carrier Sense Multiple Access with Collision Detection (ISO 
8802/3). 

DL_TPB 

Token-Passing Bus (ISO 8802/4). 

DLTPR 

Token-Passing Ring (ISO 8802/5). 

DL_METRO 

Metro Net (ISO 8802/6). 

DL_ETHER 
Ethernet Bus. 

DL_HDLC 

bit synchronous communication line. 
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DL_CHAR 

character synchronous communication line. 

DLCTCA 

channel-to-channel adapter. 

DLFDDI 

Fiber Distributed Data I nterface. 

DLOTHER 

any other medium not listed above. 

NOTE dl_mac_type is not valid until after a dl_attach_req has been issued. 

dl_reserved 

reserved field whose value must be set to zero. 
dl_current_state 

stateof the DLPI interface for the stream when the DLS provider 
issued this acknowledgment. 

dl_sap_length 

current length of the SAP component of theDLSAP address. It may 
have a negative, zero or positive. A positive value indicates the 
ordering of the SAP and PFISYCAL component within the DLSAP 
address as SAP component followed by PFIYSICAL component. A 
negative value indicates PFIYSICAL followed by the SAP. A zero 
value indicates that no SAP has yet been bound. The absolute value 
of thedl_sap_length provides the length of the SAP component within 
theDLSAP address. 

dl_service_mode 

if returned before the DL_BI N D_REQ is processed, this conveys 
which services modes the DLS provider can support. It contains a 
bit-mask specifying on or more than oneof the foil owing values: 

DLCODLS 

connection-oriented data link service. 

DL CLDLS 
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connect ion-I ess data link service. 

DL_H P_RAWDLS 
raw-mode service. 

DL_ACLDLS 

acknowledged connectionless data link service. 

Si nee ATM is a connection-oriented link, the value of this field will 
always be DL_CODLS. 

dl_qos_length 

length, in bytes, of the negotiated/selected valuesof the quality of 
service (QOS) parameters. The returned values are those agreed 
during the negotiation. If QOS has not yet been negotiated, default 
values will be returned; these values correspond to those that will be 
applied by the DLS provider on a connect request. 

The QOS values are conveyed in the structures defined in the above 
sections in this chapter. For any parameter the DLS provider does not 
support or cannot determine, the corresponding entry will be set to 
DL_UNKNOWN. 

dl_qos_offset 

offset from the beginning of the M_PCPROTO block where the 
current QOS parameters begin. 

dl_qos_range_length 

length, in bytes, oftheavailable range of QOS parameter values 
supported by the DLS provider. This the range aval I able to the cal ling 
DLS user in a connect request. The range of available QOS values is 
conveyed in the structures defined in the following section in this 
chapter. For any parameter the DLS provider does not support or 
cannot determi ne, the correspond! ng entry wi 11 be set to 
DL_UNKNOWN. 

dl_qos_range_offset 

offset from the beginning of the M_PCPROTO block where the 
available range of quality of service parameters begins. 

dl_provider_style 
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style of DLS provider associated with the DLPI stream. The foil owing 
provider classes are defined. 

DL_STYLE1 

PPA is implicitly attached to the DLPI stream by opening the 
appropriate major/mi nor device number. 

DL_STYLE2 

DLS user must explicitly attach a PPA tothe DLPI stream using 
DLATTACHREQ. 

ATM DLPI only supports DL_STYLE2. 

dl_addr_offset 

offset of the address that is bound tothe associated stream. If the 
DLS user issues a DLJ NFO_REQ prior to binding a DLSAP, the 
value of dl_addr_len will be 0 and consequently indicate that there 
has been no address bound. 

dl_version 

current supported version of the DLPI. 
dl_brdcst_addr_length 

length of the physical broadcast address. ATM DLPI does not support 
broadcast addresses and therefore, the value of this field will be zero. 

dl_brdcst_addr_offset 

not applicable to ATM DLPI. 

dl_growth 

growth field for future use. The value of this field will be zero. 

State 

The message is valid in any state in response to a DL_I NFO_REQ. 

New State 

The resulting state is unchanged. 
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DL_ATTACH_REQ 

Requests the DLS provider to associate a physical point of attachment 
(PPA) with a stream. 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

Format 

typedef struct { 

ulong dl_primitive; 

ulong dl_ppa; 

} dl_a11 a ch_re q_t; 

Parameters 

dl_primitive 

DL_ATTACH_REQ 

dl_ppa 

identifier of the physical point of attachment to be associated with the 
stream. 

State 

The message is valid in state DL_UNATTACH ED. 

New State 

The resulting state is DL_ATTACH_PEN Dl NG. 

Response 

If the attach request is successful, DL_OK_ACK is sent to the DLS user 
resulting in state DL_UNBOUND. 

If the request fails, DL_ERROR_ACK is returned and the resulting state 
is unchanged. 

Reasons for Failure 

DL_BADPPA 

The specified PPA is invalid. 

DLACCESS 

The DLS user did not have proper permission to use the requested 
PPA. 
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DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_DETACH_REQ 

Requests the DLS provider to disassociate a physical point of attachment 
(PPA) with a stream. 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

Format 

typedef struct { 

ulong dl_primitive; 

) dl_detach_req_t; 

Parameters 

dl_primitive 

DLDETACHREQ 

State 

The message is valid in state DL_UNBOUND. 

New State 

The resulting state is DL_DETACH_PE N Dl NG. 

Response 

If the detach request is successful, DL_OK_ACK is sent to the DLS user 
resulting in state DL_UN ATTACH ED. 

If the request fails, DL_ERROR_ACK is returned and the resulting state 
is unchanged. 

Reasons for Failure 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DL SYSERR 
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A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_BIND_REQ 

Requests the DLS provider to bind a DLSAP to the stream. The DLS 
user must identify the address of the DLSAP to be bound to the stream. 
The DLS user also indicates whether it will accept incoming connection 
requests on the stream. Finally, the request directs the DLS provider to 
activate the stream associated with the DLSAP. 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

Format 


typedef struct { 


ulong 

dl_primitive; 

ulong 

dl_sap; 

ulong 

dl_max_conind; 

ushort 

dl_service_mode 

ushort 

dl_conn_mgmt; 

ulong 

} dl_bind_req_t; 

dl_xidtest_fIg; 


Parameters 

dl_primitive 

DLBINDREQ 

dl_sap 

DLSAP that will be bound to the DLPI stream. 
dl_max_conind 

maximum number of outstanding DL_CONNECT_l ND messages 
allowed on the DLPI stream. If the value is zero, the stream cannot 
accept any DL_CON N ECT_I N D messages. I f greater than zero, the 
DLS user will accept DL_CONNECT_l ND messages up to the given 
value before having to respond with a DL_CONNECT_RES or a 
DLDISCONNECTREQ. 

dl_service_mode 

desired mode of service for this stream. This field should beset to one 
of the following: 

DL CODLS 
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connection-m<xle 

DLCLDLS 

con n ect i on I ess- mode 
DL_H P_RAWDLS 
raw-mode 
dl_conn_mgmt 

indicates that the stream is the "connection management" stream for 
the PPA to which the stream is attached. This field should beset to 
zero. 

dl_xidtest_flg 

indicates to the DLS provider that XID and/or TEST responses for 
this stream are to be automatically generated by the DLS Provider. 

State 

The message is valid in state DL_UNBOUND. 

New State 

The resulting state is DL_BI ND_PENDI NG. 

Response 

If the bind request is successful, DL_BI ND_ACK is sent tothe DLS user 
resulting in state DL_I DLE. 

If the request fails, DL_ERROR_ACK is returned and the resulting state 
is unchanged. 

Reasons for Failure 

DLBADADDR 

The DLSAP address information was invalid or was in an incorrect 
format. 

DLJNITFAILED 

Automatic initialization of the PPA failed. 

DL_NOTINIT 

The PPA had not been initialized prior to this request. 

DL ACCESS 
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The DLS user did not have proper permission to use the requested 
DLSAP address. 

DLBOUND 

The DLS user attempted to bind a second stream to a DLSAP with 
dl_max_conind greater than zero, or the DLS user attempted to bind 
a second "connection management" stream to a PPA. 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLNOADDR 

The DLS provider could not allocate a DLSAP address for this 
stream. 

DL_UNSUPPORTED 

The DLS provider does not support requested service mode on this 
stream. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLNOAUTO 

Automatic handling of XID and TEST responses not supported. 
DLNOXIDAUTO 

Automatic handling of XID response not supported. 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DL_BIND_ACK 

Reports the successful bind of a DLSAP to a stream, and returns the 
bound DLSAP address to the DLS user. This primitive is generated in 
response of a DL_BIND_REQ. 

The message consists of one M_PCPROTO message block, which 
contains the following structure. 

Message Format 
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typedef struct { 


ulong 

dl_primitive; 

ulong 

dl_sap; 

ulong 

dl_addr_length 

ulong 

dl_addr_o f f s et 

ulong 

dl_max_conind; 

ulong 

} dl_bind_ack_t; 

dl_xidtest_f Ig 


Parameters 

dl_primitive 

DL_BIND_ACK 

dl_sap 

DLSAP address information associated with the bound DLSAP. It 
corresponds to the dl_sap field of the associated DL_BI N D_REQ, 
which contains part of the DLSAP address. 

dl_addr_length 

length of the complete DLSAP address that was bound to the DLPI 
stream. 

dl_addr_offset 

offset from the beginning of the M_PCPROTO block where the 
DLSAP address begins. 

dl_max_conind 

allowed maximum number of outstanding DL_CONNECT_IND 
messages to be supported on the DLPI stream. 

dl_xidtest_flg 

XID and TEST responses supported by the provider. 

State 

The message is valid in state DL_BI ND_PENDI NG. 

New State 

The resulting state is DLJ DLE. 

DL_UNBIND_REQ 

Requests the DLS provider to unbind the DLSAP that had been bound by 
a previous DL_BIND_REQ from this stream. 
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The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

Format 

typedef struct { 

ulong dl_primitive; 

} dl_unbind_req_t; 

Parameters 

cll_primitive 

DL_UNBIND_REQ 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is DL_U N Bl N D_PE N DING. 

Response 

If theunbind request is successful, DL_OK_ACK issent totheDLS user 
resulting in state DL_UNBOUND. 

If the request fails, DL_ERROR_ACK is returned and the resulting state 
is unchanged. 

Reasons for Failure 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_SUBS_BIND_REQ 

Requests the DLS provider bind a subsequent DLSAP to the stream. The 
DLS user must identify the address of the subsequent DLSAP to be 
bound to the stream. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 
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typedef struct { 

ulong dl_primitive; 

ulong dl_subs_sap_offset; 

ulong dl_subs_sap_length; 

ulong dl_subs_bind_class; 

) dl_subs_bind_req_t; 

Parameters 

dl_primitive 

DL_SUBS_BIND_REQ 
dl _su bs_sap_offset 

offset of the DLSAP from the beginning of the M_PROTO block, 
dl _su bs_sap_l engt h 

length of the specified DLSAP. 
dl_subs_bind_class 

specifies either peer or hierarchical addressing. 

DL_PEER_BIND 

specifies peer addressing. The DLSAP specified is used in lieu of 
the DLSAP bound in the BIND request. 

DL_H I E RARCHI CAL_BI N D 

specifies hierarchical addressing. The DLSAP specified is used in 
addition to the DLSAP specified using the BIND request. 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is DL_SUBS_BI ND_PND. 

Response 

If the subsequent bind request is successful, DL_SUBS_BI ND_ACK is 
sent to the DLS user resulting in state DL_I DLE. 

Reasons for Failure 

DLBADADDR 

The DLSAP address information was invalid or was in an incorrect 
format. 
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DL_ACCESS 

The DLSAP user did not have proper permission to use the requested 
DLSAP address. 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLUNSUPPORTED 

Requested addressing class not supported. 

DL_TOOMANY 

Limit exceeded on the maximum number of DLSAPs per stream. 

DL_SUBS_BIND_ACK 

Reports the successful bind of a subsequent DLSAP to a stream, and 
returns the bound DLSAP address to the DLS user. This primitive is 
generated in responsetoa DL_SUBS_BIND_REQ. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_subs_sap_offset; 

ulong dl_subs_sap_length; 

) dl_subs_bind_ack_t; 

Parameters 

dl_primitive 

DL_SUBS_BIND_ACK 
dl _su bs_sap_offset 

offset of the DLSAP from the beginning of the M_PCPROTO block, 
dl _su bs_sap_l engt h 

length of the specified DLSAP. 
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State 

The message is valid in state DL_SUBS_BI ND_PND. 

New State 

The resulting state is DLJ DLE. 

DL_SUBS_UNBIND_REQ 

Requests the DLS provider to unbind the DLSAP that had been bound by 
a previous DL_SUBS_BI ND_REQ from this stream. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_subs_sap_offset; 

ulong dl_subs_sap_length; 

) dl_subs_unbind_req_t; 

Parameters 

dl_primitive 

DL_SUBS_UNBIND_REQ 
dl _su bs_sap_offset 

offset of the DLSAP from the beginning of the M_PROTO block, 
dl _su bs_sap_l engt h 

length of the specified DLSAP. 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is DL_SU BS_U N Bl N D_PN D. 

Response 

If the unbind request is successful, a DL_OK_ACK is sent to the DLS 
User. The resulting state is DL_I DLE. 

If the request fails, DL_ERROR_ACK is returned and the resulting state 
is unchanged. 
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Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLBADADDR 

The DLSAP address information was invalid or was in an incorrect 
format. 

DL_ENABMULTI_REQ 

Requests the DLS Provider to enable specific multicast addresses on a 
per Stream basis. It is invalid for a DLS Provider to pass upstream 
messages that are destined for any address other than those explicitly 
enabled on that Stream by the DLS User. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure: 

typedef struct { 

ulong dl_primitive; 

ulong dl_addr_length; 

ulong dl_addr_offset; 

} dl_enabmulti_req_t; 

Parameters 

dl_primitive 

DL_ENABMULTI_REQ 

dl_addr_length 

length of the multicast address. 
dl_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
multicast address begins. 

State 
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This message is valid in any state in which a Icxial acknowledgment is 
not pending with the exception of DL_UN ATTACH. 

New State 

The resulting state is unchanged. 

Response 

If the enable request is successful, a DL_OK_ACK issent totheDLS 
user. If the request fails, DL_ERROR_ACK is returned and the resulting 
state is unchanged. 

Reasons for Failure 

DLBADADDR 

Address information was invalid or was in an incorrect format. 
DL_TOOMANY 

Too many multicast address enable attempts. Limit exceeded. 
DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLNOTSUPPORTED 

Primitive is known, but not supported by the DLS Provider. 

DL_DISABMULTI_REQ 

Requests the DLS Provider to disable specific multicast addresses on a 
per Stream basis. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure: 

typedef struct { 

ulong dl_primitive; 

ulong dl_addr_length; 

ulong dl_addr_offset; 

) dl_disabmulti_req_t; 

Parameters 

dl_primitive 

DL_DISABMULTI_REQ 
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dl_addr_length 

length of the physical address. 
dl_addr_offset 

offset form the beginning of the M_PROTO message block wherethe 
multicast address begins. 

State 

This message is valid in any state in which a local acknowledgment is 
not pending with the exception of DL_UN ATTACH. 

New State 

The resulting state is unchanged. 

Response 

If the disable request is successful, a DL_OK_ACK issent totheDLS 
user. If the request fails, DL_ERROR_ACK is returned and the resulting 
state is unchanged. 

Reasons for Failure 

DLBADADDR 

Address information was invalid or in an incorrect format. 
DL_NOTENAB 

Address specified is not enabled. 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLNOTSUPPORTED 

Primitive is known, but not supported by the DLS Provider. 

DL_PROMISCON_REQ 

This primitive requests the DLS Provider to enable promiscuous mode 
on a per Stream basis, either at the physical level or at the SAP level. 

TheDL Provider will route all received messages on the media to the 
DLS User until either a DL_DETACH_REQ or a 
DL_PROMI SCOFF_REQ is received or the Stream is closed. 
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Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_level; 

} dl_promiscon_req_t; 

Parameters 

cll_primitive 

DLPROMISCONREQ 

dljevel 

indicates promiscuous mode at the physical or SAP level. 
DL_PROMISC_PHYS 

Before or after the STREAM has been bound, the DLPI user 
receives all traffic on the wire regardless of protocol or physical 
address. 

DL_PROMISC_SAP 

Before or after the STREAM has been bound, the DLPI user 
receives all traffic destined for this interface (physical addresses, 
broadcast addresses or bound multicast addresses) that matches 
any protocol enabled on that interface. 

DL_PROMISC_MULTI 

Before or after the STREAM has been bound, the DLPI user 
receives all multicast packets on the wire regardless of the 
protocol it is destined for. 

State 

The message is valid in any state when there is no pending 
acknowledgment. 

New State 

The resulting state is unchanged. 

Response 

If enabling of promiscuous mode is successful, a DL_OK_ACK is 
returned. Otherwise, a DL_ERROR_ACK is returned. 
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Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLNOTSUPPORTED 

Primitive is known but not supported by the DLS Provider. 
DL_UNSUPPORTED 

Requested service is not supplied by the provider. 

DL_PROMISCOFF_REQ 

This primitive requests the DLS Provider to disable promiscuous mode 
on a per Stream basis, either at the physical level or at the SAP level. 

Format 

The message consists of one M_PROTO message block, which contains 
the foil owing structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_level; 

} dl_promiscoff_req_t; 

Parameters 

dl_primitive 

DLPROMISCOFFREQ 

dijevel 

indicates promiscuous mode at the physical or SAP level. 
DL_PROMISC_PHYS 

Before or after the STREAM has been bound, the DLPI user 
receives all traffic on the wire regardless of protocol or physical 
address. 

DL_PROMISC_SAP 
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Before or after the STREAM has been bound, the DLPI user 
receives all traffic destined for this interface (physical addresses, 
broadcast addresses or bound multicast addresses) that matches 
any protocol enabled on that interface. 

DL_PROMISC_MULTI 

Before or after the STREAM has been bound, the DLPI user 
receives all multicast packets on the wire regardless of the 
protocol it is destined for. 

State 

The message is valid in any state in which the promiscuous mode is 
enabled and there is no pending acknowledgment. 

New State 

The resulting state is unchanged. 

Response 

If the promiscuous mode disabling is successful, a DL_OK_ACK is 
returned. Otherwise, a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLNOTSUPPORTED 

Primitive is known but not supported by the DLS Provider. 
DL_NOTENAB 
Mode not enabled. 

DL_OK_ACK 

Acknowledges tothe DLS user that a previously issued request primitive 
was received successfully. It is only initiated for those primitives that 
require a positive acknowledgment. 
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Format 

The message consists of one M_PCPROTO message block, which 
contains the following structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_correct_primitve; 

} dl_ok_a ck_t; 

Parameters 

cll_primitive 

DLOKACK 

cll_correct_primitive 

identifies the successfully received primitive that is being 
acknowledged. 

State 

The message is valid in response to a DL_ATTACH_REQ, 
DL_DETACH_REQ, DL_UNBIND_REQ, DL_CONNECT_RES, 

DL RESET RES, DL DISCON REQ, DL SU BS_U N Bl N D REQ, 
DL_PROMISCON_REQ, DL_ENABMULTI_REQ, 

DL_DI SADM U LTI_REQ or DL_PROM ISCOF F_REQ from any of several 
states as defined in Appendix B, Allowable Sequence of DLPI Primitives, 
of the DLPI 2.0 specification. 

New State 

The resulting state depends on the current state and is defined fully in 
Appendix B, Allowable Sequence of DLPI Primitives, of the DLPI 2.0 
specification. 

DL_ERROR_ACK 

I nforms the DLS user that the previous request or response was invalid. 

Format 

The message consists of one M_PCPROTO message block, which 
contains the following structure. 

typedef struct { 

ulong dl_primitive; 

ulong dl_error_primitive; 
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ulong dl_errno; 

ulong dl_unix_errno; 

} dl_error_ack_t;_ 

Parameters 

dl_primitive 

DL_ERROR_ACK 

dl_error_primitive 

primitive that is in error. 
dl_errno 

DLPI error code associated with the failure. 
dl_unix_errno 

UNIX system error code associated with the failure. This value 
should be non-zero only when dl_errno is set to DL_SYSE RR. 11 is 
used to report UNIX system fai I ures that prevent the process! ng of a 
given request or response. 

State 

The message is valid in every state where an acknowledgement or 
confirmation of a previous request or response is pending. 

New State 

The resulting state is that from which the acknowledged request or 
response was generated. 

Optional Primitives to Perform Essential 
Management Functions 

This section describes optional primitives. Someof these primitives may 
not be supported by the DLS provider. 

DL_PHYS_ADDR_REQ 

Requests the DLS provider to return the physical address associated 
with the stream depending upon the value of the address type selected in 
the request. 

Format 
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The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_addr_type; 

} dl_phys_addr_req_t; 

Parameters 

cll_primitive 

DL_PHYS_ADDR_REQ 

cll_aclclr_type 

type of address requested - factory physical address or current 
physical address 

DL_FACT_PHYS_ADDR 

DL_CURR_PHYS_ADDR 

State 

The message is valid in any attached state in which a local 
acknowledgement is not pending. For a style 2 provider, this would be 
after a PPA is attached using the DL_ATTACFI_REQ. For a style 1 
provider, the PPA is implicitly attached after the stream is opened. 

New State 

The resulting state is unchanged. 

Response 

The provider responds to the request with a DL_PFIYS_ADDR_ACK if 
the request is supported. Otherwise, a DL_ERROR_ACK is returned. 

Reasons for Failure 

DLNOTSUPPORTED 

The primitive is known, but not supported by the DLS provider. 
DL_OUTSTATE 

The primitive was issued from an invalid state. 
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This primitive returns the value for the physical address to the link user 
in response to a DL_PHYS_ADDR_REQ. 

Format 

The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_addr_length; 

ulong dl_addr_offset; 

} dl_phys_addr_ack_t; 

Parameters 

dl_primitive 

DL_PHYS_ADDR_ACK 

dl_addr_length 

length of the requested hardware address. 
dl_addr_offset 

offset from beginning of the M_PROTO message block. 

State 

The message is valid in any state in response to a 
DL_PHYS_ADDR_REQ. 

New State 

The resulting state is unchanged. 

D L_SE T_P H YS_AD D R_R E Q 

Sets the physical address value for all streams for that provider for a 
particular PPA. 

Format 

The message consists one M_PROTO message block containing the 
structure shown below. 
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typedef struct { 

ulong dl_primitive; 

ulong dl_addr_length; 

ulong dl_addr_offset; 

} dl_set_phys_addr_req_t; 

Parameters 

dl_primitive 

DL_SET_PHYS_ADDR_REQ 

dl_addr_length 

length of the requested hardware address. 
dl_addr_offset 

offset from beginning of the M_PROTO message block. 

State 

The message is valid in any attached state in which a local 
acknowledgement is not pending. For a style 2 provider, this would be 
after a PPA is attached using the DL_ATTACH_REQ. For a style 1 
provider, the PPA is implicitly attached after the stream is opened. 

New State 

The resulting state is unchanged. 

Response 

The provider responds to the request with a DL_OK_ACK on successful 
completion. Otherwise, a DL_ERROR_ACK is returned. 

Reasons for Failure 

DLBADADDR 

The address information was invalid or was in an incorrect format. 
DLNOTSUPPORTED 

The primitive is known, but not supported by the DLS provider. 
DLSYSERR 

A system error has occurred. 

DL_OUTSTATE 

The primitive was issued from an invalid state. 
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DLBUSY 

One or more streams for that particular PPA are in the DL_BOUND 
state. 

DL_GET_STATISTICS_REQ 

Directs the DLS provider to return statistics. 

Format 

The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

) dl_get_statistics_req_t; 

Parameters 

dl_primitive 

D L_G E T_STAT I ST IC S_R E Q 

State 

The message is valid in any attached state in which a local 
acknowledgement is not pending. 

New State 

The resulting state is unchanged. 

Response 

The DLS provider responds to the request with a 
DL_GET_STATISTICS_ACK if the primitive is supported. Otherwise, a 
DL_ERROR_ACK is returned. 

Reasons for Failure 

DLNOTSUPPORTED 

The primitive is known, but not supported by the DLS provider. 

DL_G ET_STATI STIC S_AC K 

Returns statistics in response to the DL_GET_STATI STICS_REO. The 
content of this statistics block is the following: 

Format 
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The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_stat_length; 

ulong dl_stat_offset; 

) dl_get_statistics_ack_t; 

Parameters 

cll_primitive 

DL_GET_STATI STI CS_ACK 
cll_stat_length 

length of the statistics structure. 
cll_stat_offset 

offset from the beginning of the M_PCPROTO message block where 
the statistics information resides. 

State 

The message is valid in any state in response to a 
D L G E T STATI ST IC S_R E Q. 

New State 

The resulting state is unchanged. 

The DL_GET_STATI STICS_ACK returns standard mib and optionally 
extended mib information for all HP supported networking interfaces. It 
is up to the DLPI user to check the interface-specific field of the I nterface 
MIB to determi ne whether there is a transmission MIB. 

DL_H P_MU LTIC AST_L I ST_RE Q 

Requests the DLS Provider to return a list of all currently enabled 
multicast addresses on a specific LAN interface. 

Format 

The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

} dl_hp_muiticast_list_req_t;_ 
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Parameters 

dl_primitive 

DL_H P_M U LTI CAST_L I ST_REQ 

State 

The message is valid in any state in which there is not a local 
acknowledgment pending with the exception of DL_UN ATTACH. 

New State 

The resulting state is unchanged. 

Response 

If the multicast request is successful, a 

DL_HP_MULTICAST_LIST_ACK is sent to the DLS user. If the requests 
fails, DL_ERROR_ACK is returned and the resulting state is unchanged. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_HP_MULTICAST_LIST_ACK 

Reports the successful completion of a DL_HP_MULTICAST_LIST_REQ 
primitive. A complete list of the multicast addresses for a specific LAN 
interface are returned after the control message header. 

Format 

The message consists one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_offset; 

ulong dl_length; 

ulong dl_count; 

} dl_hp_multicast_list_ack_t; 

Parameters 
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dl_primitive 

DL_H P_M U LTI CAST_L I ST_ACK 
dl_offset 

offset to the data in the multicast acknowledgment, 
dijength 

length of data area, in bytes. 
dl_count 

total number of 6 byte multicast addresses in the data area of the 
multicast acknowledgment. 

State 

The message is valid in any state in response to a 
DL_H P_M U LTI CAST_L I ST_REQ. 

New State 

The resulting state is unchanged. 
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Connectionless-mode Service Primitives 

This section describes the connect ion I ess-mode service primitives. 

DL_UNITDATA_REQ 

Conveys one DLSDU from the DLS user totheDLS provider for 
transmission to a peer DLS user. 

Because connect ion I ess data transfer is an unacknowledged service, the 
DLS provider makes no guarantees of delivery of connectionless 
DLSDU s. It is the responsibility of the DLS user to do any necessary 
sequencing or retransmission of DLSDUs in the event of a presumed 
loss. 

Priority messages are currently only supported over lOOVG. To send a 
priority message over lOOVG, a user must have superuser capabilities 
and set the dl_priority fields in the DL_UNITDATA_REQ primitive to 
the foil owing values: 

dl_min must be set to 0. 

dl_max must be set to 1. 

Thedl_priority field will be ignored on interfaces which do not support 
priority messages. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below, followed by one or more M_DATA blocks 
containing at least one byte of data. The amount of user data that may be 
transferred in a single DLSDU is limited. This limit is conveyed by the 
parameter dl_max_sdu in the DL_I NFO_ACK primitive. 

typedef struct { 

ulong dl_primitive; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

dl_priority_t dl_priority; 

} dl_unitdata_req_t; 

Parameters 

dl_primitive 

DL_UNITDATA_REQ 
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dl _dest_addr_l engt h 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_priority 

priority value within the supported range for this particular DLSDU. 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is unchanged. 

Response 

If the DLS provider accepts the data for transmission, there is no 
response. This does not, however, guarantee that the data will be 
delivered to the destination DLS user, si nee the connectionless data 
transfer is not a confirmed service. 

If the request is erroneous, DL_UDERROR_l ND is returned, and the 
resulting state is unchanged. 

If for some reason the request cannot be processed, the DLS provider 
may generate a DL_U DE RROR_l N D to report the problem. There is, 
however, no guarantee that such an error report will be generated for all 
undeliverable data units, since connectionless data transfer is not a 
confirmed service. 

Reasons for Failure 

DLBADADDR 

The destination DLSAP address was in an incorrect format or 
contained invalid information. 

DL_BADDATA 

The amount of data in the current DLSDU exceeded the DLS 
provider's DLSDU limit. 
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DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLUNSUPPORTED 

Requested priority not supplied by provider. 

DL_UNITDATAJND 

Conveys one DLSDU from the DLS provider totheDLS user. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below, followed by one or more M_DATA blocks 
containing at least one byte of data. The amount of user data that may be 
transferred in a single DLSDU is limited. This limit is conveyed by the 
parameter dl_max_sdu in the DL_I NFO_ACK primitive. 

typedef struct { 


ulong 

dl_primitive; 

ulong 

dl_dest_addr_length 

ulong 

dl_de st_addr_o f f s et 

ulong 

dl_src_addr_length; 

ulong 

dl_src_addr_of f set; 

ulong 

dl_group_addre s s; 


) dl_unitdata_ind_t; 

Parameters 

dl_primitive 

DL_UNITDATAJND 

dl_dest_addr_length 

length of the address of the DLSAP where this DL_UNITDATA_I ND 
is intended to be delivered. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_src_addr_length 

length of the DLSAP address of the sending DLS user, 
dl src addr offset 
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offset from the beginning of the M_PROTO message block wherethe 
source DLSAP address begins. 

dl_group_address 

is set by the DLS provider upon receiving and passing upstream a 
data message when the destination address of the data message is a 
multicast or broadcast address. 

State 

The message is valid in any attached state. 

New State 

The resulting state is unchanged. 

DL_UDERRORJND 

I nforms the DLS user that a previously sent DL_UNITDATA_REQ 
produced an error or could not be delivered. The primitive indicates the 
destination DLSAP address associated with the failed request, and 
conveys an error value that specifies the reason for failure. 

Format 

The message consists of either one M_PROTO message block or one 
M_PCPROTO message block containing the structure shown below. 

typedef struct { 


ulong 

dl_primitive; 

ulong 

dl_dest_addr_length; 

ulong 

dl_dest_addr_offset; 

ulong 

dl_unix_errno; 

ulong 

dl_errno; 

} dl_uderror_ind_t; 


Parameters 


dl_primitive 



DLUDERRORJND 

dl_dest_addr_length 


length of the DLSAP address of the destination DLS user, 
dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 
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dl_unix_errno 

UNIX system error code associated with the failure. This value 
should be non-zero only when dl_errno is set to DL_SYSE RR. 11 is 
used to report UNIX system failures that prevent the processing of a 
given request. 

dl_errno 

DLPI error code associated with the failure. See Reasons for Failure 
in the description of DL_UNITDATA_REQ for the error codes that 
apply to an erroneous DL_UNITDATA_REQ. In addition, the error 
value DL_UN DELIVERABLE may be returned if the request was 
valid but for some reason the DLS provider could not deliver the data 
unit (e.g. due to lack of sufficient local buffering to store the data 
unit). There is, however, no guarantee that such an error report will 
be generated for all undeliverable data units, since connectionless 
data transfer is not a confirmed service. 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is unchanged. 


90 


Chapter 2 




DLPI Primitives 

Raw Mode Service Primitives 


Raw Mode Service Primitives 

This section describes the raw mode service primitives. 

DL_HP_RAWDATA_REQ 

Requests the DLS provider to send one completely formatted DLSDU to 
a peer DLS user. The DLSDU is assumed to have a complete Link and 
MAC Level header included. 

As with connectionless data transfer, raw mode is an unacknowledged 
service, and the DLS provider makes no guarantees of delivery of 
connectionless DLSDUs. It istheresponsibility oftheDLS user todoany 
necessary sequencing or retransmission of DLSDUs in the event of a 
presumed loss. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below, followed by one or more M_DATA message blocks 
containing at least one byte of data. The amount of user data that may be 
transferred in a single DLSDU is limited. This limit is conveyed by the 
parameter dl_max_sdu in the DL_I NFO_ACK primitive. 

typedef struct { 

ulong dl_primitive; 

) dl_hp_rawdata_req_t; 

Parameters 

dl_primitive 

DL_H P_RAWDATA_REQ 

State 

The message is valid in state DLJ DLE. 

New State 

The resulting state is unchanged. 

Response 
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If the DLS provider accepts the data for transmission, there is no 
response. This does not, however, guarantee that the data will be 
delivered to the destination DLS user, si nee the connectionless data 
transfer is not a confirmed service. 

If the request is erroneous, a DL_ERROR_ACK is returned, and the 
resulting state is unchanged. 

Reasons for Failure 

DL_BADPRIM 

Request was issued from a state in which the 
DL_H P_RAWDATA_REQ was not recognized. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_H P_R AWD ATA_I N D 

Conveys one completely formatted DLSDU from the DLS provider to the 
DLS user. The DLSDU contains the complete Link and MAC Level 
headers. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below, followed by one or more M_DATA message blocks 
containing at least one byte of data. The amount of user data that may be 
transferred in a single DLSDU is limited. This limit is conveyed by the 
parameter dl_max_sdu in the DL_I NFO_ACK primitive. 

typedef struct { 

ulong dl_primitive; 

} dl_hp_rawdata_ind_t; 

Parameters 

dl_primitive 

DL_H P_RAWDATA_I N D 

State 

The message is valid in state DLJ DLE. 

New State 
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The resulting state is unchanged. 
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Connection-mode Service Primitives 

This section describes the service primitives that support the 
connection-mode service of the data link layer. These primitives support 
the establishment of connections, connection-mode data transfer, and 
connection release services. 

In the connection establishment model, the calling DLS user initiates a 
request for a connection, and the called DLS user receives each request 
and either accepts or rejects it. I n the simplest form, the called DLS user 
is passed a connect indication and the DLS provider holds any 
subsequent indications until a response for the current outstanding 
indication is received. At most one connect indication is outstanding at 
any time. 

DLPI also enables a called DLS user to multi-thread connect indications 
and responses. The DLS provider will pass all connect indications to the 
called DLS user (up to some pre-established limit as set by 
DL_BI ND_REQ and DL_BI ND_ACK). The called DLS user may then 
respond to the requests in any order. 

To support multi-threading, a correlation value is needed to associate 
responses with the appropriate connect indication. A correlation value is 
contained in each DL_CONNECT_l ND, and the DLS user must use this 
value in the DL_CONNECT_RES or DL_DISCONNECT_REQ primitive 
used to accept or reject the connect request. 

Once a connection has been accepted or rejected, the correlation value 
has no meaning to a DLS user. The DLS provider may reuse the 
correlation value in another DL_CONNECT_l ND. 

Connection-Oriented DLPI Extensions 

These primitives areonly valid on connection-oriented DLPI STREAMS. 
Connection-oriented DLPI streams are those on which a DL_BIND_REQ 
with dl_service_mode set to DL_CODLS has been done. 

DL_HPJNFO_REQ 

Requests the DLS provider to provide information on the state of the 
connection on a DLPI stream. 
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Format 

typedef struct { 

u_long dl_primitive; 

} dl_hp_info_req_t; 

Parameters 

dl_primitive 

DL_H PJNFO_REQ 

State 

The message is valid in the states DL_I DIE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_FIP_INFO_ACK. Otherwisea DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_HPJNFO_ACK 

This message is sent in response to a DL_FIP_I NFO_REQ; it conveys 
information on the state of the connection on a DLPI stream. 

Format 

typedef struct { 

u_long dl_primitive; 
u_long dl_mem_fails; 
u_long dl_queue_fails; 
u_long dl_ack_to; 
u_long dl_p_to; 
u_long dl_rej_to; 
u_long dl_busy_to; 
u_long dl_send_ack_to; 
u_long dl_ack_to_cnt; 
u_long dl_p_to_cnt; 
u_long dl_rej_to_cnt; 
u_long dl_busy_to_cnt; 
u_long dl_local_win; 
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u_long dl_remote_win; 
u_long dl_i_pkts_in; 
u_long dl_i_pkts_in_oos; 
u_long dl_i_pkts_in_drop; 
u_long dl_i_pkts_out; 
u_long dl_i_pkts_retrans; 
u_long dl_s_pkts_in; 
u_long dl_s_pkts_out; 
u_long dl_u_pkts_in; 
u_long dl_u_pkt s_out; 
u_long dl_bad_pkts; 
u_long dl_retry_cnt; 
u_long dl_max_retry_cnt; 
u_long dl_max_retries; 
u_long dl_ack_thresh; 
u_long dl_remote_busy_cnt; 
u_long dl_hw_req_fails; 

} dl_hp_inf o_ack_t; 

Parameters 

dl_primitive 

DL_H PJNFO_ACK 

dl_mem_fails 

number of memory allocations that have failed. 

dl_queue_fails 

number of times that the DLS provider was unable to forward a 
message because the queue was ful I. 

dl_ack_to 

length of the ACK timeout in tenths of a second. The ACK timeout 
determines the length of time that LLC Type 2 will wait for an 
acknowledgment of any outstanding I PDUs or for a response to a U 
PDU before attempting to force a response. 

dl_p_to 

length of the P timeout in tenths of a second. The P timeout 
determines the length of time that LLC Type 2, after sending a 
command with the P bit set to 1, will wait for a response with the F 
bit set to 1 before attempting to force a response. 

dl_rej_to 

length of the REJ timeout in tenths of a second. The REJ timeout 
determines the length of time that LLC Type2 will wait for a 
response to a REJ PDU before attempting to force a response. 
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dl_busy_to 

length of the BUSY timeout in tenths of a second. The BUSY timeout 
determines the length of time that LLC Type 2 will wait for an 
indication that a remote busy condition has been cleared before 
attempt! ng to force a response. 

dl_send_ack_ti meout 

length of theSEND_ACK timeout in tenths of a second. The 
SEND_ACK timeout determines the maximum length of time that 
LLC Type 2 will delay acknowledgment of I PDUs if it has not 
received dl_send_ack_threshold I PDUs. 

dl_ack_to_cnt 

number of times that the ACK timer has expired. 
dl_p_to_cnt 

number of times that the P timer has expired. 
dl_rej_to_cnt 

number of times that the REJ timer has expired. 
dl_busy_to_cnt 

number of times that the BUSY timer has expired. 
dl_local_win 

size of the LLC Type 2 local receive window. 
dl_remote_win 

size of the L LC Type 2 remote receive wi ndow. 
dl_i_pkts_in 

number of I PDUs correctly received. 
dl_i_pkts_in_oos 

number of I PDUs received out of sequence. 
dl_i_pkts_in_drop 

number of I PDUs correctly received, but which weredropped because 
of a lack of resources. 
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dl_i_pkts_out 

number of I PDUs acknowledged by the remote system. 
dl_i_pkts_retrans 

number of I PDUs re-transmitted. 
dl_s_pkts_in 

number of S PDUs received. 
dl_s_pkts_out 

number of S PDUs transmitted. 
dl_u_pkts_in 

number of U PDUs received. 
dl_u_pkts_out 

number of U PDUs transmitted. 
dl_bad_pkts 

number of PDUs with bad control fields received. 
dl_retry_cnt 

most recent number of ti mes that L LC Type 2 has attempted to force 
a response from the remote due to a timer expiration. This value is 
re-set to 0 when a response is received. 

dl_max_retry_cnt 

maximum value that dl_retry_cnt has attained. 
dl_max_retries 

maximum allowed number of retries before re-setting the connection. 
This is sometimes known as the N2 variable. 

dl_ack_thresh 

maximum number of I PDUs that can be received before an 
acknowledgment is sent. If this threshold is reached, an 
acknowledgment is sent and the SEND_ACK timer is restarted. 

dl_remote_busy_cnt 
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number of times that the remote system has reported that it was 
busy. 

dl_hw_req_fails 

number of times that LLC Type 2 has been unable to transmit due to 
congestion in the interface device driver or interface card. 

State 

The message is valid in any state in response to a DL_H PJ NFO_REQ. 

New State 

The resulting state is unchanged. 

DL_H P_SET_AC K_TO_RE Q 

Requests the DLS provider tosettheACK timeout to the specified value. 

Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_ack_to; 

) dl_hp_set_ack_to_req_t; 

Parameters 

dl_primitive 

DL_H P_SET_ACK_TO_REQ 
dl_ack_to 

new valueof theACK timeout in tenthsof a second. The AC K timeout 
determines the length of time that LLC Type 2 will wait for an 
acknowledgment of any outstanding I PDUs or for a response to a U 
PDU before attempting to force a response. 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DI_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 
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If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_H P_SET_P_TO_RE Q 

Requests the DLS provider to set the P timeout to the specified value. 

Format 

typedef struct { 

u_long dl_primitive; 
u_long dl_p_to; 

) dl_hp_set_p_to_req_t; 

dl_primitive 

DL_H P_SET_P_TO_REQ 
dl_p_to 

new val ue of the P ti meout i n tenths of a second. The P ti meout 
determines the length of time that LLC Type 2, after sending a 
command with the P bit set to 1, will wait for a response with the F 
bit set to 1 before attempting to force a response. 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 
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DL_HP_SET_REJ _TO_REQ 

Requests the DLS provider to set the REJ timeout to the specified value. 

Format 

typedef struct { 

u_long dl_primitive; 
u_long dl_rej_to; 

) dl_hp_set_rej_to_req_t; 

Parameters 

dl_primitive 

DL_H P SET REJ _TO_REQ 
dl_rej_to 

new value of the REJ timeout in tenths of a second. The REJ timeout 
determines the length of time that LLC Type 2 will wait for a 
response to a REJ PDU before attempting to force a response. 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_HP_SET_BUSY_TO_REQ 

Requests the DLS provider to set the BUSY timeout to the specified 
value. 

Format 
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typedef struct { 

u_long dl_primitive; 
u_long dl_busy_to; 

) dl_hp_set_busy_to_req_t; 

Parameters 

dl_primitive 

DL_H P_SET_BUSY_TO_REQ 
dl_busy_to 

new value of the BUSY timeout in tenths of a second. The BUSY 
timeout determines the length of time that LLC Type 2 will wait for 
an indication that a remote busy condition has been cleared before 
attempting to force a response. 

State 

The message is valid in the states DL_I DIE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

D L_H P_SE T_SE N D_AC K_TO_R E Q 

Requests the DLS provider to set the SEND_ACK timeout to the 
specified value. 

Format 

typedef struct { 

u_long dl_primitive; 
u_long dl_send_ack_to; 

} dl_hp_s et_s en d_a c k_t o_re q_t; 

Parameters 
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dl_primitive 

DL_H PSETSE N D_ACK_TO_REQ 
dl_send_ack_to 

new valueof theSEND_ACK timeout in tenths of a second. The 
SEND_ACK timeout determines the maximum length of time that 
LLC Type 2 will delay acknowledgment of I PDUs if it has not 
received dl_send_ack_threshold I PDUs. 

State 

The message is valid in the states DL_I DIE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_HP_SET_MAX_RETRIES_REQ 

Requests the DLS provider to set the maximum allowed number of 
retries to the specified value. 

Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_max_retries; 

} dl_hp_set_max_retries_req_t; 

Parameters 

dl_primitive 

DL_H P_SET_MAX_RETRIES_REQ 
dl max retries 
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maximum allowed number of retries before re-setting the connection. 
This is sometimes known as the N2 variable. 

The message is valid in the states DL_I DIE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_H P_SET_AC K_TH R E SH_RE Q 

Requests the DLS provider to set the acknowledgment threshold to the 
specified value. 

NOTE Setting the ack thresh will not affect the local window size. 

Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_ack_thresh; 

} dl_hp_set_ack_thresh_req_t; 

Parameters 

dl_primitive 

DL_H P_SET_ACK_THRESH_REQ 
dl_ack_thresh 

maximum number of I PDUs that can be received before an 
acknowledgment is sent. If this threshold is reached, an 
acknowledgment is sent andtheSEND_ACK timer is restarted. This 
value cannot be greater than the remote receive window size. 

State 
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The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the specified dl_ack_thresh is valid and the primitive was issued from 
a valid state, the DLS provider responds with a DL_OK_ACK. Otherwise 
a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

If the specified dl_ack_thresh is greater than the remote receive 
window size, then a DL_ERROR_ACK with dl_errnoset to 
DL_SYSERR and dl_unix_errno set to El NVAL is returned. 

DL_H P_SET_LOC AL_WI N_RE Q 

Requests the DLS provider to set the local window size to the specified 
value. 


NOTE Setting the local window size also causes the DLPI read sidestreams 

queue hi water mark to beset to (local_window_size* MTU). The 
(local_window_size* MTU) cannot exceed (1 «16) - (2 * MTU). 


Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_local_win; 

} dl_hp_set_local_win_req_t; 

Parameters 

dl_primitive 

DL_H P_SET_LOCAL_WI N_REQ 
dl local win 
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sizeof thelcxial receive window. This value must be greater than 0 
and less than 128. 

State 

The message is valid in the states DL_I DIE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the specified dl_local_win is valid and the primitive was issued from a 
valid state, the DLS provider responds with a DL_OK_ACK. Otherwisea 
DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

If the specified dl_local_win is invalid, then a DL_ERROR_ACK with 
dl_errno set to DL_SYSERR and dl_unix_errno set to El NVAL is 
returned. 

DL_H P_SET_RE MOTE_WI N_RE Q 

Requests the DLS provider to set the remote wi ndow size to the specified 
value. 

NOTE Setting the remote window size causes the ack thresh to be set to 

((remote_window_size +1) / 2). 

Format 

typedef struct { 

u_long dl_primitive; 

u_long dl_remote_win; 

} dl_hp_set_remote_win_req_t; 

Parameters 

dl_primitive 


106 


Chapter 2 




DLPI Primitives 

Connection-mode Service Primitives 


DL_H P_SET_RE MOTE_WI N_REQ 
dl_remote_win 

size of the remote receive window. This value must be greater than 0 
and less than 128. 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the specified dl_remote_win is valid and the primitive was issued from 
a valid state, the DLS provider responds with a DL_OK_ACK. Otherwise 
a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLSYSERR 

If the specified dl_remote_win is invalid, then a DL_ERROR_ACK 
with dl_errnoset to DL_SYSERR and dl_unix_errnoset toEl NVAL is 
returned. 

D L_H P_C L E AR_STATS_R E Q 

Requests the DLS provider to zerothe mem_fails, queue_fails, 
ack_to_cnt, p_to_cnt, rej_to_cnt, busy_to_cnt, i_pkts_in, i_pkts_in_oos, 
i_pkts_i n_drop, i_pkts_out, i_pkts_retrans, s_pkts_in, s_pkts_out, 
u_pkts_in, u_pkts_out, bad_pkts, max_retry_cnt, remote_busy_cnt, and 
hw_req_faiIs statistics which are reported in theDL_H P_INFO_ACK 
primitive. 

Format 

typedef struct { 

u_long dl_primitive; 

) dl_hp_clear_stats_req_t; 
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Parameters 

dl_primitive 

DL_H P_CLEAR_STATS_REQ 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDING, and DL_PROV_RESET_PENDING. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DL_HP_SET_LOCAL_BUSY_REQ 

Requests that the DLS provider inform the remote system that the local 
system is busy and cannot accept new data packets. 

Format 

typedef struct { 

u_long dl_primitive; 

) dl_hp_set_local_busy_req_t; 

Parameters 

dl_primitive 

DL_H PSETLOCALBUSYREQ 

State 

The message is valid in state I DLE. 

New State 

The resulting state is unchanged. 

Response 
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If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

D L_H P_C L E AR_L OC AL_B U SY_R E Q 

Requests that the DLS provider inform the remote system that the local 
system is no longer busy and is again able to accept new data packets. 

Format 

typedef struct { 

u_long dl_primitive; 

) dl_hp_clear_local_busy_req_t; 

Parameters 

dl_primitive 

DL_H PCLEARLOCALBUSYREQ 

State 

The message is valid in the states DL_I DLE, DL_DATAXFER, 
DL_OUTCON_PENDI NG, DLJ NCON_PENDI NG, 
DL_USER_RESET_PENDI NG, and DL_PROV_RESET_PENDI NG after 
a DL_HP_SET_LOCAL_BUSY_REQ message. 

New State 

The resulting state is unchanged. 

Response 

If the primitive is issued from a valid state, the DLS provider responds 
with a DL_OK_ACK. Otherwise a DL_ERROR_ACK is returned. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 
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DL_CONNECT_REQ 

Requests the DLS provider to establish a data link connection with a 
remote DLS user. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

ulong dl_qos_length; 

ulong dl_qos_offset; 

ulong dl_growth; 

} dl_connect_req_t; 

Parameters 

dl_primitive 

DLCONNECTREQ 

dl_dest_addr_length 

length of the DLSAP address that identifies the DLS user with whom 
a connection is to be established. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_qos_length 

length of the quality of service (QOS) parameter values desired by the 
DLS user initiating a connection. 

dl_qos_offset 

offset from the beginning of the M_PROTO message block wherethe 
quality of service parameters begin. 

dl_growth 

defines a growth field for future enhancements to this primitive. Its 
val ue must be set to zero. 

State 

The primitive is valid in state DL_I DLE. 
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New State 

The resulting state is DL_OUTCON_PENDI NG. 

Response 

There is no immediate response to the connect request. However, if the 
connect request isaccepted by the called DLS user, DL_CONNECT_CON 
is sent to the calling DLS user, resulting in state DL_DATAXFER. 

If the request is erroneous, DL_ERROR_ACK is returned and the 
resulting state is unchanged. 

Reasons for Failure 

DLBADADDR 

The destination DLSAP address was in an incorrect format or 
contained invalid information. 

DLBADQOSPARAM 

The quality of service parameters contained invalid values. 
DLBADQOSTYPE 

The qual ity of service structure type was not supported by the DLS 
provider. 

DLACCESS 

The DLS user did not have proper permission to use the responding 
stream. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_CONNECTJND 

Conveys to the local DLS user that a remote (calling) DLS user wishes to 
establish a data link connection. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 
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typedef struct { 

ulong dl_primitive; 

ulong dl_correlation; 

ulong dl_called_addr_length; 

ulong dl_called_addr_offset; 

ulong dl_calling_addr_length; 

ulong dl_calling_addr_offset; 

ulong dl_qos_length; 

ulong dl_qos_offset; 

ulong dl_growth; 

} dl_connect_ind_t; 

Parameters 

dl_primitive 

DL_CONNECTJND 

dl_correlation 

correlation number to be used by the DLS user to associate this 
message with the DL_CON N ECT_RES, DL_DI SCON N ECT_REQ, or 
DL_DI SCON N ECT_I N D that is to follow. 

dl_called_addr_length 

length of the address of the DLSAP for which this 
DL_CONNECT_l ND primitive is intended. 

dl_cal led_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
called DLSAP address begins. 

dl_cal I i ng_addr_l ength 

length of the address of the DLSAP from which the 
DL_CONNECT_RE0 primitive was sent. 

dl_cal I i ng_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
calling DLSAP address begins. 

dl_qos_length 

length of quality of service parameter values desired by the calling 
DLS user. 

dl_qos_offset 

offset from the beginning of the M_PROTO message block wherethe 
quality of service parameters begin. 
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dl_growth 

growth field for future enhancements to this primitive. Its value will 
be set to zero. 

State 

The message is valid in state DL_I DIE, or state DL_I NCON_PENDI NG 
when the maximum number of outstanding DL_CONNECT_l ND 
primitives has not been reached on this stream. 

New State 

The resulting state is DLJ NCON_PENDI NG, regardless of the current 
state. 

Response 

TheDLS user must eventually send either DL_CONNECT_RES to 
accept the connect request or DL_DI SCONNECT_REQ to reject the 
connect request. I n either case, the responding message must convey the 
correlation number received in the DL_CONNECT_l ND. The DLS 
provider will use the correlation number to identify the connect request 
to which the DLS user is responding. 

DL_CONNECT_RES 

Directs the DLS provider to accept a connect request from a remote 
(calling) DLS user on a designated stream. The DLS user may accept the 
connection on the same stream where the connect indication arrived, or 
on a different stream that has been previously bound. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 
ulong 
ulong 
ulong 
ulong 
ulong 
ulong 

} dl_connect_res 

Parameters 

dl_primitive 

DLCONNECTRES 


dl_primitive; 
dl_correlation; 
dl_resp_token; 
dl_qos_length; 
dl_qos_offset; 
dl_growth; 
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correlation number that was received with the DL_CONNECT_l ND 
associated with the connection request. The DLS provider will usethe 
correlation number to identify the connect indication to which the 
DLS user is responding. 

dl_resp_token 

if non-zero, thetoken associated with the responding stream on which 
the DLS provider is to establish the connection; this stream must be 
attached to a PPA and bound to a DLSAP. 

dl_qos_length 

length of the quality of service parameter. This should be the same 
parameter specified in the DL_CONNECT_l ND. 

dl_qos_offset 

offset from the beginning of the M_PROTO message block where the 
quality of service parameters begin. 

dl_growth 

growth field for future enhancements to this primitive. Its value will 
be set to zero. 

State 

The primitive is valid in state DL_I NCON_PENDI NG. 

New State 

The resulting state is DL_CONN_RES_PENDI NG. 

Response 

If the connect response is successful, DL_OK_ACK is sent to the DLS 
user. If no outstanding connect indications remain, the resulting state for 
the current stream is DL_IDLE; otherwise, it remains 
DL_I NCON_PENDI NG. For the responding stream (designated by the 
parameter dl_res_token), the resulting state is DL_DATAXFER. If the 
current stream and responding stream are the same, the resulting state 
of that stream is DL_DATAXF E R. These streams may only be the same 
when the response corresponds to the only outstandi ng connect 
indication. 
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If the request fails, DL_ERROR_ACK is returned on the stream where 
the DL_CONNECT_RES primitive was received, and the resulting state 
of that stream and the responding stream is unchanged. 

Reasons for Failure 

DLBADTOKEN 

The token for the responding stream was not associated with a 
currently open stream. 

DLBADQOSPARAM 

The quality of service parameters contained invalid values. 
DLBADQOSTYPE 

The qual ity of service structure type was not supported by the DLS 
provider. 

DLBADCORR 

The correlation number specified in this primitive did not correspond 
to a pending connect indication. 

DLACCESS 

The DLS user did not have proper permission to use the responding 
stream. 

DL_OUTSTATE 

The primitive was issued from an invalid state, or the responding 
stream was not in a valid state for establishing a connection. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_PENDING 

Current stream and responding stream is the same and there is more 
than one outstanding connect indication. 

DL_CONNECT_CON 

I nforms the local DLS user that the requested data link connection has 
been established. 
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Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 


typedef struct 
ulong 
ulong 
ulong 
ulong 
ulong 
ulong 


} dl_connect_con_t; 

Parameters 

cll_primitive 


dl_primitive; 
dl_resp_addr_length 
dl_r e s p_addr_o f f s e t 
dl_qos_lenth; 
dl_qos_of f set; 
dl_growth; 


DLCONNECTCON 

cll_resp_aclclr_length 

length of the address of the responding DLSAP associated with the 
newly established data link connection. 

dl_resp_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
responding DLSAP address begins. 

dl_qos_length 

length of the quality of service parameter theDLS user selected when 
issued the DL_CON N ECT_REQ. 

dl_qos_offset 

offset from the beginning of the M_PROTO message block wherethe 
quality of service parameter begin. 

dl_growth 

growth field for future enhancements to this primitive. Its value will 
be set to zero. 

State 

The message is valid in state DL_OUTCON_PENDI NG. 

New State 

The resulting state is DL_DATAXFER. 
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DL_TOKEN_REQ 

Requests that a connection response token be assigned to the stream and 
returned tothe DLS user. This token can be supplied in the 
DL_CONNECT_RES primitive to indicate the stream on which a 
connection will be established. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

) dl_token_req_t; 

Parameters 

dl_primitive 

DLTOKENREQ 

State 

The message is valid in any state in which a local acknowledgement is 
not pending, as described in Appendix B, Allowable Sequence of DLPI 
Primitives, of the DLPI 2.0 specification. 

New State 

The resulting state is unchanged. 

Response 

The DLS provider responds to the information request with a 
DLTOKENACK. 

DL_TOKEN_ACK 

This message is sent in response to DL_TOKEN_REQ; it conveys the 
connection response token assigned to the stream. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_token; 

} dl_token_ack_t; 
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Parameters 

dl_primitive 

DLTOKENACK 

dl_token 

connection response token associated with the stream. This value 
must be a non-zero value. The DLS provider will generate a token 
value for each stream upon receipt of the first DL_TOKEN_REQ 
primitive issued on that stream. The same token value will be 
returned in response to all subsequent DL_TOKEN_REQ primitives 
issued on a stream. 

State 

The message is valid in any state in response to a DL_TOKEN_REQ. 

New State 

The resulting state is unchanged. 

DL_DATA_REQ 

Conveys a complete DLS Data Unit (DLSDU) from the DLS user to the 
DLS provider for transmission over the data link connection. 

Format 

The message consists of one or moreM_DATA message blocks containing 
at least one byte of data. 

State 

The message is valid in state DL_DATAXFER. If it is received in state 
DLJDLE or DL_PROV_RESET_PENDI NG, it should be discarded 
without generating an error. 

New State 

The resulting state is unchanged. 

Response 

If the request is valid, no response is generated. If the request is 
erroneous, a STREAMS M_ERROR message should be issued to the DLS 
user specifying an errno value of E PROTO. This action should be 
interpreted as a fatal, unrecoverable, protocol error. A request is 
considered erroneous under the following conditions. 
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• The primitive was issued from an invalid state. If the request is 
issu^ in state DL_IDLE or DL_PROV_RESET_PENDI NG, however, 
it is silently discarded with no fatal error generated. 

• The amount of data in the current DLSDU is not within the DLS 
provider's acceptable bounds as specified by dl_min_sdu and 
dl_max_sdu in the DL_I NFO_ACK. 

DL_DATAJND 

Conveys a DLSDU from the DLS provider to the DLS user. 

Format 

The message consists of one or moreM_DATA message blocks containing 
at least one byte of data. 

State 

The message is valid in state DL_DATAXFER. 

New State 

The resulting state is unchanged. 

DL_DISCONNECT_REQ 

Requests the DLS provider to disconnect an active data link connection 
or one that was in the process of activation, either outgoing or incoming, 
as a result of an earlier DL_CON N ECTJ N D or DL_CON N ECT_REQ. If 
an incoming DL_CONN ECTJ ND is being refused, the correlation 
number associated with that connect indication must be supplied. The 
message indicates the reason for the disconnection. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 
ulong 
ulong 
ulong 

} dl_disconnect_ 

Parameters 

dl_primitive 

DLDISCONNECTREQ 


dl_primitive; 
dl_reason; 
dl_correlation; 
req_t; 
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dl_reason 

reason for the disconnection. 

DL_DISC_NORMAL_CONDITION: normal release of a data link 
connection. 

DL_DISC_ABNORMAL_CONDITION: abnormal release of a data 
link connection. 

DL_CONREJ _PERMANENT_COND: a permanent condition caused 
the rejection of a connect request. 

DL_CONREJ _TRANSI ENT_COND: a transient condition caused the 
rejection of a connect request. 

DL_UNSPECI FI ED: reason unspecified 

dl_correlation 

if non-zero, conveys the correlation number that was contained in the 
DL_CONNECT_l ND being rejected. This value permits the DLS 
provider to associate the primitive with the proper 
DL_CONNECT_l ND when rejecting an incoming connection. If 
disconnect request is releasing a connection that is already 
established, or is aborting a previously sent DL_CONNECT_REQ, 
the value of dl_correlation should be zero. 

State 

The message is valid in any of the states: DL_DATAXFER, 

DLJ NCON_PENDI NG, DL_OUTCON_PENDI NG, 
DL_PROV_RESET_PENDING, DL_USER_RESET_PENDI NG. 

New State 

The resulting state is one of the disconnect pending states, as defined in 
Appendix B, Allowable Sequence of DLPI Primitives, of the DLPI 2.0 
specification. 

Response 

If the disconnect is successful, DL_OK_ACK issent totheDLS user 
resulting in state DL_I DLE. 

If the request fails, DL_ERROR_ACK is returned, and the resulting 
state is unchanged. 

Reasons for Failure 
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DLBADCORR 

The correlation number specified in this primitive did not correspond 
to a pending connect indication. 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_DISCONNECTJND 

I nforms the DLS user that the data link connection on this stream has 
been disconnected, or that a pending connection (either 
DL_CON N ECT_REQ or DL_CON N ECT_I N D) has been aborted. This 
primitive indicates the origin and the cause of the disconnect. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_originator; 

ulong dl_reason; 

ulong dl_correlation; 

} dl_disconnect_ind_t; 

Parameters 

dl_primitive 

DL_DISCONNECTJND 

dl_originator 

whether the disconnect was DLS user or DLS provider originated 
(DL_USER or DL_PROVIDER, respectively). 

dl_reason 

the reason for the disconnection: 

DL_DI SC_PE RM AN E NT_CON Dl Tl ON: connection release due to 
permanent connection. 
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DL_DI SC_TRAN SI E NT_CON Dl Tl ON: connection released due to 
transient connection. 

DL_CONREJ _DEST_UNKOWN: unknown destination for connect 
request. 

DL_CONREJ _DEST_UNREACH_PERMANENT: could not reach 
destination for connect request - permanent condition. 

DL_CONREJ _DEST_UNREACH_TRANSIENT: could not reach 
destination for connect request - transient condition. 

DL_CON REJ _QOS_U NAVAI L_PERM ANE NT: requested quality of 
service parameters permanently unavailable during connection 
establishment. 

DL_CONREJ _QOS_UNAVAI L_TRANSI ENT: requested quality of 
service parameters temporarily unavailable during connection 
establishment. 

DL_UNSPECI FI ED: reason unspecified 
dl_correlation 

if non-zero, the correlation number that was contained in the 
DL_CONNECT_l ND that is being aborted. This value permits the 
DLS user to associate the message with the proper 
DL_CONNECT_l ND. If the disconnect indication is indicating the 
release of a connection that is already established, or is indicating the 
rejection of a previously sent DL_CONNECT_REQ, the value of 
dI_correlation should be zero. 

State 

The message is valid in any of the states: DL_DATAXFER, 

DLJ NCON_PENDI NG, DL_OUTCON_PENDI NG, 
DL_PROV_RESET_PENDING, DL_USER_RESET_PENDI NG. 

New State 

The resulting state is DLJ DLE. 

DL_RESET_REQ 

Requests that the DLS provider initiatethe re-synchronization of a data 
link connection. This service is abortive, so no guarantee of delivery can 
be assumed about data that is in transit when the reset request is 
initiated. 
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Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

) dl_reset_req_t; 

Parameters 

cll_primitive 

DLRESETREQ 

State 

The message is valid in state DL_DATAXFER. 

New State 

The resulting state is DL_U SE R_RESET_PE N DING. 

Response 

If the disconnect is successful, DL_OK_ACK issent totheDLS user 
resulting in state DL_I DIE. 

If the request fails, DL_ERROR_ACK is returned, and the resulting 
state is unchanged. 

Reasons for Failure 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_RESETJND 

I nforms the DLS user that either the remote DLS user is 
re-synchronizing the data link connection, ortheDLS provider is 
reporting loss of data for which it can not recover. The indication conveys 
the reason for the reset. 

Format 
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The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

ulong dl_originator; 

ulong dl_reason; 

} dl_reset_ind_t; 

Parameters 

cll_primitive 

DLRESETREQ 

cll_originator 

whether the reset was originated by the DLS user or DLS provider 
(DL_USER or DL_ PROVIDER, respectively). 

dl_reason 

reason for the reset: 

DL_RESET_FLOW_CONTROL: indicates flow control congestion 

DL_RESET_LI NK_ERROR: indicates a data link error situation 

DL_RESET_RESYNCH: indicates a request for re-synchronization of 
a data link connection. 

State 

The message is valid in state DL_DATAXFER. 

New State 

The resulting state is DL_PROV_RESET_PENDI NG. 

Response 

TheDLS user should issuea DL_RESET_RES primitive to continue the 
resynchronization procedure. 

DL_RESET_RES 

Directs the DLS provider to complete re-synchronizing the data link 
connection. 

Format 
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The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

) dl_reset_res_t; 

Parameters 

cll_primitive 

DL_RESET_RES 

State 

The primitive is valid in state DL_PROV_RESET_PENDI NG. 

New State 

The resulting state is DL_RESET_RES_PENDI NG. 

Response 

If the reset response is successful, DL_OK_ACK is sent tothe DLS user 
resulting in state DL_DATAXFER. 

If thereset response is erroneous, DL_ERROR_ACK is returned, and the 
resulting state is unchanged. 

Reasons for Failure 

DL_OUTSTATE 

The primitive was issued from an invalid state. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DL_RESET_CON 

I nforms the reset-initiating DLS user that the reset has completed. 

Format 

The message consists of one M_PROTO message block containing the 
structure shown below. 

typedef struct { 

ulong dl_primitive; 

) dl_reset_con_t; 
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Parameters 

dl_primitive 

DLRESETCON 

State 

The message is valid in state DL_USER_RESET_PENDI NG. 

New State 

The resulting state is DL_DATAXFER. 
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Primitives to Handle XID and TEST 
Operations 

This section describes the primitives used for XID and TEST operations. 

DL_TEST_REQ 

Conveys the TEST command DLSDU from the DLS user totheDLS 
provider for transmission to a peer DLS provider. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

} dl_test_req_t; 

Parameters 

dl_primitive 

DLTESTREQ 

dl_flag 

flag values for the request as follows: 

DL_POLL_FI NAL indicates if the poll/final bit is set. 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

State 
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The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 

The resulting state is unchanged. 

Response 

On an invalid TEST command request, a DL_ERROR_ACK is issued to 
the user. If the DLS provider receives a response from the remote side, a 
DL_TEST_CON is issued tothe DLS user. It is recommended that the 
DLS user use a timeout procedure to recover from a situation when there 
is no response from the peer DLS user. 

Reasons for Failure 

DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLBADADDR 

DLSAP address information was invalid or was in an incorrect 
format. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLNOTSUPPORTED 

Primitive is known but not supported by the DLS provider. 
DL_TESTAUTO 

Previous bind request specified automatic handling of TEST 
responses. 

DL_UNSUPPORTED 

Requested service not supplied by provider. 

DL_TESTJND 

Conveys the TEST indication DLSDU from the DLS provider tothe DLS 
user. 

Format 
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The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

ulong dl_src_addr_length; 

ulong dl_src_addr_offset; 

} dl_test_ind_t; 

Parameters 

dl_primitive 

DL_TESTJND 

dl_flag 

flag values associated with the received TEST frame: 

DL_POLL_FI NAL indicates if the poll/final bit is set. 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_src_addr_length 

length of the source DLSAP address. If the source user is 
implemented using DLPI, this address is the full DLSAP address 
returned on the DL_BI ND_ACK. 

dl_src_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
source DLSAP address begins. 

State 

The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 
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The resulting state is unchanged. 

Response 

The DLS user must respond with a DL_TEST_RES. 

DL_TEST_RES 

Conveys the TEST response DLSDU from the DLS user to the DLS 
provider in response to a DL_TEST_IND. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

} dl_test_res_t; 

Parameters 

dl_primitive 

DL_TEST_RES 

dl_flag 

flag values for the response as follows: 

DL_POLL_FI NAL indicates if the poll/final bit is set. 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block where the 
destination DLSAP address begins. 

State 

The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 
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The resulting state is unchanged. 

DL_TEST_CON 

Conveys the TEST response DLSDU from the DLS provider totheDLS 
user in response to a DL_TEST_REQ. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

ulong dl_src_addr_length; 

ulong dl_src_addr_offset; 

} dl_test_con_t; 

Parameters 

dl_primitive 

DL_TEST_CON 

dl_flag 

flag values for the request as follows: 

DL_POLL_FI NAL indicates if the poll/final bit is set. 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_src_addr_length 

length of the source DLSAP address. If the source user is 
implemented using DLPI, this address is the full DLSAP address 
returned on the DL_BI ND_ACK. 

dl src addr offset 
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offset from the beginning of the M_PROTO message block wherethe 
source DLSAP address begins. 

State 

The message is valid in states DL_I DIE and DL_DATAXFER. 

New State 

The resulting state is unchanged. 

DL_XID_REQ 

Conveys one XID DLSDU from the DLS user to the DLS provider for 
transmission to a peer DLS user. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

} dl_xid_req_t; 

Parameters 

dl_primitive 

DLXIDREQ 

dl_flag 

flag values for the response as follows: 

DL_POLL_FI NAL indicates status of the poll/final bitinthexid 
frame. 

dl_dest_addr_length 

length of the DLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 
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State 

The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 

The resulting state is unchanged. 

Response 

On an invalid XID request, a DL_ERROR_ACK is issued tothe user. If 
the remote side responds to the XID request, a DL_XID_CON will be 
sent tothe user. It is recommended that the DLS user use a timeout 
procedure on an XI D_REQ. The timeout may be used if the remote side 
does not respond to the XID request. 

Reasons for Failure 

DL_BADDATA 

The amount of data in the current DLSDU exceeded the DLS 
provider's DLSDU limit. 

DLXIDAUTO 

Previous bind request specified provider would handle XID. 
DL_OUTSTATE 

Primitive was issued from an invalid state. 

DLBADADDR 

The DLSAP address information was invalid or was in an incorrect 
format. 

DLSYSERR 

A system error has occurred and the UNIX system error is indicated 
intheDL_ERROR_ACK. 

DLNOTSUPPORTED 

Primitive is known but not supported by the DLS provider. 

DL_XIDJND 

Conveys an XID DLSDU from the DLS provider tothe DLS user. 

Format 
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The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

ulong dl_src_addr_length; 

ulong dl_src_addr_offset; 

} dl_xid_ind_t; 

Parameters 

dl_primitive 

DLXIDJND 

dl_flag 

flag values associated with the received XID frame: 

DL_POLL_FI NAL indicates if the received xid frame had the 
poll/final bit set. 

dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_src_addr_length 

length of the source DLSAP address. If the source user is 
implemented using DLPI, this address is the full DLSAP address 
returned on the DL_BI N D_ACK. 

dl_src_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
source DLSAP address begins. 

State 

The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 
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The resulting state is unchanged. 

Response 

The DLS user must respond with a DL_XI D_RES. 

DL_XID_RES 

Conveys an XID DLSDU from the DLS user tothe DLS provider in 
response to a DL_XI D_l N D. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or more M_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

} dl_xid_res_t; 

Parameters 

dl_primitive 

DLXIDRES 

dl_flag 

flag values associated with the received XID frame: 
DL_POLL_FINAL 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block where the 
destination DLSAP address begins. 

State 

The message is valid in states DL_I DLE and DL_DATAXFER. 

New State 
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The resulting state is unchanged. 

DL_XID_CON 

Conveys an XID DLSDU from the DLS provider tothe DLS user in 
response to a DL XID REQ. 

Format 

The message consists of one M_PROTO message block, followed by zero 
or moreM_DATA blocks containing zero or more bytes of data. The 
message structure is as follows: 

typedef struct { 

ulong dl_primitive; 

ulong dl_flag; 

ulong dl_dest_addr_length; 

ulong dl_dest_addr_offset; 

ulong dl_src_addr_length; 

ulong dl_src_addr_offset; 

} dl_xid_con_t; 

Parameters 

dl_primitive 

DLXIDCON 

dl_flag 

flag values associated with the received XID frame: 
DL_POLL_FINAL 
dl_dest_addr_length 

length of theDLSAP address of the destination DLS user. If the 
destination user is implemented using DLPI, this address is the full 
DLSAP address returned on the DL_BI ND_ACK. 

dl _dest_addr_offset 

offset from the beginning of the M_PROTO message block wherethe 
destination DLSAP address begins. 

dl_src_addr_length 

length of the source DLSAP address. If the source user is 
implemented using DLPI, this address is the full DLSAP address 
returned on the DL_BI ND_ACK. 

dl src addr offset 
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offset from the beginning of the M_PROTO message block wherethe 
source DLSAP address begins. 

State 

The message is valid in states DL_I DIE and DL_DATAXFER. 

New State 

The resulting state is unchanged. 
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DLPI States 

Table2-1 describesthe states asscxiated with DLPI. It presents the state 
name used in the state transition table, the corresponding DLPI state 
name used throughout this specification, a brief description of the state, 
and an indication of whether the state is valid for connect ion-oriented 
data link service (DL_CODLS), connectionless data link service 
(DL_CLDLS), acknowledged connectionless data link service (ACLDLS) 
or all. 


Table2-1 DLPI States 


State 

DLPI State 

Description 

Service 

Type 

0) UNATTACHED 

DL_UNATTACH ED 

Stream opened but PPA 
not attached 

ALL 

1) ATTACH PEND 

DL ATTACH 

PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DL_ATTACH_REQ 

ALL 

2) DETACH PEND 

DL DETACH 

PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLDETACHREQ 

ALL 

3) UNBOUND 

DL_UNBOUND 

Stream is attached but not 
bound to a DLSAP 

ALL 

4) BIND PEND 

DL_BIND_PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLBINDREQ 

ALL 

5) UNBIND PEND 

DL UNBIND 

PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLUNBINDREQ 

ALL 

6) IDLE 

DLJDLE 

The stream is bound and 
activated for use- 
connection establishment 
or connectionless data 
transfer may take place 

ALL 
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State 

DLPI State 

Description 

Service 

Type 

7) UDQOS PEND 

DL UDOOS 

PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DL_UDOOS_REO 

DLCLDLS 

8)OUTCON PEND 

DL OUTCON 
PENDING 

An outgoing connection is 
pending - the DLS user is 
waiting for a 
DLCONNECTCON 

DLCODLS 

9) INCON PEND 

DL INCON 

PENDING 

An incoming connection is 
pending-the DLS provider 
is waiting for a 
DLCONNECTRES 

DLCODLS 

10) CONN RES 
PEND 

DL CONN RES 
PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLCONNECTRES 

DLCODLS 

11) DATAXFER 

DLDATAXFER 

Connect ion-mode data 
transfer may take place 

DLCODLS 

12) USER RESET 
PEND 

DL USER RESET 
PENDING 

A user-initiated reset is 
pending - the DLS user is 
waiting for a 
DLRESETCON 

DLCODLS 

13) PROV RESET 
PEND 

DL PROV RESET 
PENDING 

A provider-initiated reset 
is pending - the DLS 
provider iswaitingfor a 
DL_RESET_RES 

DLCODLS 

14) RESET RES 
PEND 

DL RESET RES 
PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DL_RESET_RES 

DLCODLS 

15) DI SCON 8 

PEND 

DL DISCON8 

ENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLDISCONNECTREO 
issued from the 
DLOUTCONPENDING 
state 

DLCODLS 
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State 

DLPI State 

Description 

Service 

Type 

16) DI SCON 9 

PEND 

DL DISCON9 
PENDING 

TheDLS user iswaitingfor 
an acknowledgement of a 
DLDISCONNECTREO 

1 ssued from the 

DLJNCON_PENDING 

state. 

DLCODLS 

17) DI SCON 11 
PEND 

DL Dl SCON 11 
PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLDISCONNECTREO 
issued from the 
DL_DATAXFER state 

DLCODLS 

18) DI SCON 12 
PEND 

DL Dl SCON 12 
PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLDISCONNECTREO 
issued from the 

DL USER RESET 
PENDING state 

DLCODLS 

19) DI SCON 13 
PEND 

DL Dl SCON 13 
PENDING 

TheDLS user iswaitingfor 
an acknowledgment of a 
DLDISCONNECTREO 
issued from the 

DL PROV RESET 
PENDING state 

DL_CODLS 

20) SUBS BIND 
PEND 

DL SUBS BIND 

PND 

TheDLS user iswaitingfor 
an acknowledgment of a 
DL_SUBS_BIND_REO 

ALL 

21) SUBS 

UNBIND PEND 

DL SUBS UNBIND 
PND 

TheDLS user iswaitingfor 
an acknowledgment of a 
DL_SUBS_UNBIND_REO 

ALL 


The following rules apply to the maintenance of DLPI state: 

• The DLS provider is responsible for keeping a record of thestateof 
the interface as viewed by the DLS user, to be returned in the 
DLJNFO_ACK. 
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• The DLS provider may never generates primitive that places the 
i nterface out of state. 

• If the DLS provider generates a STREAMS M_ERROR message 
upstream, it should free any further primitives processed by its write 
side put or service procedure. 

• The close of a stream is considered an abortive action by the DLS 
user, and may be executed from any state. The DLS provider must 
issue appropriate indications to the remote DLS user when a close 
occurs. For example, if the DLPI state is DL_DATAXFER, a 

DL_DI SCONNECT_l ND should be sent to the remote DLS user. The 
DLS provider should free any resources associated with that stream 
and reset the stream to its unopened condition. 

The follow! ng points clarify the state transition table. 

• IftheDLS provider supports connect! on-mode service, the value of 
theoutcnt state variable must be initialized tozerofor each stream 
when that stream is first opened. 

• The initial and final state for a style 2 DLS provider is 
DL_UNATTACFIED. Flowever, because a style 1 DLS provider 
implicitly attaches a PPA to a stream when it is opened, the initial 
and final DLPI state for a style 1 provider is DL_UN BOUND. The 
DLS user should not issue DL_ATTACH_REQ or DL_DETACH_REQ 
primitives to a style 1 DLS provider. 

• A DLS provider may have multiple connect indications outstanding 
(i.e. the DLS user has not responded to them) at onetime. As the 
state transition table points out, the stream on which those 
indications are outstanding will remain in the 

DL_I NCON_PENDI NG state until the DLS provider receives a 
response for all indications. 

• The DLPI state associated with a given stream may be transferred to 
another stream only when the DL_CONNECT_RES primitive 
indicates this behavior. I n this case, the responding stream (where 
the connection will be established) must be in the DL_I DLE state. 

• ThelabelingofthestatesDL_PROV_RESET_PENDING and 
DL_USER_RESET_PENDI NG indicate the party that started the 
local interaction, and does not necessarily indicate the originator of 
the reset procedure. 
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• A DL_DATA_REQ primitive received bytheDLS provider in the 
stateDL_PROV_RESET_PENDING (i.e. after a DL_RESETJ ND has 
been passed to the DLS user) or the state DLJ DIE (i.e. after a data 
link connection has been released) should be discarded by the DLS 
provider. 

• A DL_DATA_IND primitive received bytheDLS user after the user 
has issued a DL_RESET_REQ should be discarded. 

To ensure accurate processing of DLPI primitives, the DLS provider 

must adhere to the foil owing rules concerning the receipt and generation 

of STREAMS M_FLUSH messages during various state transitions. 

• The DLS provider must be ready to receive M_F LUSH messagesfrom 
upstream and flush its queues as specified in the message. 

• The DLS provider must issue an M_FLUSH message upstream to 
flush both the read and write queues after receiving a successful 
DL_UNBI ND_REQ primitive but before issuing the DL_OK_ACK. 

• If an incoming disconnect occurs when the interface is in the 
DL_DATAXFER, DL_USER_RESET_PENDI NG, or 
DL_PROV_RESET_PENDI NG state, the DLS provider must send up 
an M_FLUSH message to flush both the read and write queues before 
sending up a DL_DI SCONNECTJND. 

• If a DL_DISCONNECT_REQ is issued in the DL_DATAXFER, 
DL_USER_RESET_PENDING, or DL_PROV_RESET_PENDI NG 
states, the DLS provider must issue an M_FLUSH message upstream 
to flush both the read and write queues after receiving the successful 
DL_DISCONNECT_REQ but before issuing the DL_OK_ACK. 

• If a reset occurs when the interface is in the DL_DATAXFER or 
DL_USER_RESET_PENDI NG state, the DLS provider must send up 
an M_FLUSH message to flush both the read and write queues before 
sending up a DL_RESETJ ND or DL_RESET_CON. 
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This appendix contains sampie programs for connection, connectioniess, 
and raw modes. 
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Connection Mode 

(C) COPYRIGHT HEWLETT-PACKARD COMPANY 1992. ALL RIGHTS 
RESERVED. NO PART OF THIS PROGRAM MAY BE PHOTOCOPIED, 

REPRODUCED, OR TRANSLATED TO ANOTHER PROGRAM LANGUAGE WITHOUT 
THE PRIOR WRITTEN CONSENT OF HEWLETT PACKARD COMPANY 

-kic-k-k-k-k-k-k-kic-k-k-kic-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-^ 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

This program demonstrates data transfer over a connection oriented 
DLPI stream. It also demonstrates connection handoff. 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

tinclude <stdio.h> 
tinclude <fcntl.h> 
tinclude <memory.h> 
tinclude <sys/types.h> 
tinclude <sys/stream.h> 
tinclude <sys/stropts.h> 
tinclude <sys/dlpi.h> 
tinclude <sys/dlpi_ext.h> 

tdefine SEND_SAP 0x80 /* sending SAP */ 

tdefine RECV_SAP 0x82 /* receiving SAP */ 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

global areas for sending and receiving messages 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

tdefine AREA_SIZE 5000 /* bytes; big enough for largest possible msg */ 

tdefine LONG_AREA_SIZE (AREA_SIZE / sizeof(u_long)) /* AREA_SIZE / 4 */ 

/* these are u_long arrays instead of u_char to insure proper alignment */ 
u_long ctrl_area[LONG_AREA_SIZE]; /* for control messages */ 

u_long data_area[LONG_AREA_SIZE]; /* for data messages */ 

struct strbuf ctrl_buf = { 

AREA_SIZE, 

0 , 

ctrl_area 

}; 

struct strbuf data_buf 
AREA_SIZE, 

0 , 

data_area 

}; 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

get the next message from a stream; get_msg() returns one of the 
following defines 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 


/* maxlen = AREA_SIZE */ 

/* len gets filled in for each message */ 
/* buf = data area */ 


/* maxlen = AREA_SIZE */ 

/* len gets filled in for each message */ 
/* buf = control area */ 
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#define 

GOT_ 

_CTRL 

1 

/* 

message has only a control part */ 

#define 

GOT_ 

_DATA 

2 

/* 

message has only a data part */ 

#define 

GOT_ 

_BOTH 

3 

/* 

message has both control and data parts 

int 






get_msg 

(fd) 





f 

int 

fd; 


/* 

file descriptor */ 

1 

int 

flags = 

0; 

/* 

0 -> get any available message */ 


int 

result 

= 0; 

/* 

return value */ 


/* 






zero first byte of control area so the caller can call check_ctrl 
without checking the get_msg return value; if there was only data 
in the message and the user was expecting control or control + data, 
then when he calls check_ctrl it will compare the expected primitive 
zero and print information about the primitive that it got. 

*/ 

ctrl_area[0] = 0; 

/* call getmsg and check for an error */ 
if(getmsg(fd, &ctrl_buf, &data_buf, Sflags) < 0) { 

printf ("error: getmsg failed, errno = %d\n", errno); 
exit (1) ; 

} 

if(ctrl_buf.len > 0) { 

result 1= GOT_CTRL; 

} 

if(data_buf.len >0) { 

result 1= GOT_DATA; 

} 

return(result) ; 

} 


check that control message is the expected message 

void 


check_ctrl(ex prim) 

int ex_prim; 


{ 


/* 


dl_error_ack_t *err_ack = 


the expected primitive */ 
(dl_error_ack_t *)ctrl_area; 


/* did we get the expected primitive? */ 
if(err_ack->dl_primitive != ex_prim) { 

/* did we get a control part */ 
if(ctrl_buf.len) { 

/* yup; is it an ERROR_ACK? */ 
if(err_ack->dl_primitive == DL_ERROR_ACK) { 

/* yup; format the ERROR_ACK info */ 
printf("error: expected primitive 0x%02x, ", 
ex_prim); 

printf("got DL_ERROR_ACK\n"); 

printf (" dl_error_primitive = 0x%02x\n", 

err_ack->dl_error_primitive); 
printf (" dl_errno = 0x%02x\n", 

err_ack->dl_errno); 
printf (" dl_unix_errno = %d\n". 
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err_ack:->dl_unix_errno) ; 

exit (1) ; 

} else { 

/* 

didn't get an ERROR_ACK either; print whatever 
primitive we did get 
*/ 

printf("error: expected primitive 0x%02x, ", 
ex_prim); 

printf("got primitive 0x%02x\n", 

err_ack->dl_primitive); 

exit (1) ; 

} 

} else { 

/* no control; did we get data? */ 
if(data_buf.len) { 

/* tell user we only got data */ 

printf("error: check_ctrl found only data\n"); 
exit (1); 

} else { 

/* 

no message???; well, it was probably an 
interrupted system call 
*/ 

printf ("error: check_ctrl found no message\n"); 
exit (1) ; 


put a message consisting of only a data part on a stream 

■kic-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k-k-kici’:-k-kic-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-^ 

void 

put_data(fd, length) 

int fd; /* file descriptor */ 

int length; /* length of data message */ 

{ 

/* set the len field in the strbuf structure */ 
data_buf.len = length; 


/* call putmsg and check for an error */ 
if(putmsg(fd, 0, &data_buf, 0) < 0) { 

printf("error: put_data putmsg failed, errno = %d\n", errno) ; 
exit (1) ; 
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put a message consisting of only a control part on a stream 


void 


put_ctrl(fd. 

length, pri) 



int 

fd; 

/* 

file descriptor */ 

int 

length; 

/* 

length of control message */ 

int 

pri; 

/* 

priority of message: either 0 or RS_HIPRI 


{ 

/* set the len field in the strbuf structure */ 
ctrl_buf.len = length; 


*/ 


/* call putmsg and check for an error */ 
if(putmsg(fd, &ctrl_buf, 0, pri) < 0) { 

printf("error: put_ctrl putmsg failed, errno = %d\n", errno) ; 
exit (1) ; 





put a message consisting of both a control part and a control part 
on a stream 

■k-k-k-k-k-ki’:-k-k-k-k-k-k-k-kic-k-k-k-k-kici’:-k-kic-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

void 

put_both(fd, ctrl_length, data_length, pri) 


int 

fd; 

/* 

file descriptor */ 

int 

ctrl_length; 

/* 

length of control part */ 

int 

data_length; 

/* 

length of data part */ 

int 

pri; 

/* 

priority of message: either 0 or RS_HIPRI 


/* set the len fields in the strbuf structures */ 
ctrl_buf.len = ctrl_length; 
data_buf.len = data_length; 


/* call putmsg and check for an error */ 
if(putmsg(fd, &ctrl_buf, &data_buf, pri) < 0) { 

printf("error: put_both putmsg failed, errno = %d\n", errno); 
exit (1) ; 



^i^iri^ici^iri^ici^iri^ici^iri^ici^iri^ici^iri^-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k 

print a string followed by a DLSAP 

void 

print_dlsap(string, dlsap, dlsap_len) 

char *string; /* label */ 

u_char *dlsap; /* the DLSAP */ 
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int dlsap_len; /* length of dlsap */ 

{ 

int i; 

printf("%sOx", string); 
for(i =0; i < dlsap_len; i++) { 

printf("%02x", dlsap[i]); 

} 

printf("\n"); 

} 

open the DLPI cloneable device file, get a list of available PPAs, 
and attach to the first PPA; returns a file descriptor for the stream 

int 

attach () { 

int fd; /* file descriptor */ 

int ppa; /* PPA to attach to */ 

dl_hp_ppa_req_t *ppa_req = (dl_attach_req_t *)ctrl_area; 
dl hp ppa ack t *ppa_ack = (dl hp ppa ack t *)ctrl_area; 
dl hp ppa info t *ppa_info; 

dl_attach_req_t *attach_req = (dl_attach_req_t *)ctrl_area; 
char *mac_name; 

/* open the device file */ 

if((fd = open("/dev/dlpi", 0_RDWR)) == -1) { 

printf("error: open failed, errno = %d\n", errno) ; 
exit (1) ; 

} 


/* 

find a PPA to attach to; we assume that the first PPA on the 
remote is on the same media as the first local PPA 
*/ 

/* send a PPA_REQ and wait for the PPA_ACK */ 
ppa_req->dl_primitive = DL_HP_PPA_REQ; 
put_ctrl(fd, sizeof(dl_hp_ppa_req_t), 0); 
get_msg(fd); 

check_ctrl(DL_HP_PPA_ACK); 

/* make sure we found at least one PPA */ 
if(ppa_ack->dl_length == 0) { 

printf("error: no PPAs availableVn"); 
exit (1) ; 

} 

/* examine the first PPA */ 

ppa_info = (dl hp ppa info t *)((u_char *)ctrl_area + 
ppa_ack->dl_offset) ; 
ppa = ppa_info->dl_ppa; 
switch(ppa_info->dl_mac_type) { 

case DL_CSMACD: 
case DL_ETHER: 

mac_name = "Ethernet"; 
break; 

case DL_TPR: 

mac_name = "Token Ring"; 
break; 
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case DL_FDDI: 

mac_name = "FDDI"; 
break; 

default: 

printf ("error: unknown MAC type in ppa_info\n"); 
exit (1) ; 

} 

printf("attaching to %s media on PPA %d\n", mac_name, ppa); 

/* 

fill in ATTACH_REQ with the PPA we found, send the ATTACH_REQ, 
and wait for the OK_ACK 
*/ 

attach_req->dl_primitive = DL_ATTACH_REQ; 
attach_req->dl_ppa = ppa; 

put_ctrl(fd, sizeof(dl_attach_req_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 

/* return the file descriptor for the stream to the caller */ 
return(fd); 

} 

bind to a sap with a specified service mode and max_conind; 
returns the local DLSAP and its length 

-kic-k-k-kic-k-k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

void 

bind(fd, sap, max_conind, service_mode, dlsap, dlsap_len) 
int fd; /* file descriptor */ 

int sap; /* 802.2 SAP to bind on */ 

int max_conind; /* max # of connect indications to accept */ 

int service_mode; /* either DL_CODLS or DL_CLDLS */ 

u_char *dlsap; /* return DLSAP */ 

int *dlsap_len; /* return length of dlsap */ 

{ 

dl_bind_req_t *bind_req = (dl bind reg t *)ctrl_area; 
dl_bind_ack_t *bind_ack = (dl_bind_ack_t *)ctrl_area; 
u_char *dlsap_addr; 

/* fill in the BIND_REQ */ 
bind_req->dl_primitive = DL_BIND_REQ; 
bind_req->dl_sap = sap; 
bind_req->dl_max_conind = max_conind; 
bind_req->dl_service_mode = service_mode; 

bind_req->dl_conn_mgmt = 0; /* conn_mgmt is NOT supported */ 

bind_req->dl_xidtest_fIg =0; /* user will handle TEST & XID pkts */ 
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/* send the BIND_REQ and wait for the OK_ACK */ 
put_ctrl(fd, sizeof(dl_bind_req_t), 0); 
get_msg(fd); 

check_ctrl(DL_BIND_ACK); 

/* return the DLSAP to the caller */ 

*dlsap_len = bind_ack->dl_addr_length; 

dlsap_addr = (u_char *)ctrl_area + bind_ack->dl_addr_offset; 
memcpy(dlsap, dlsap_addr, *dlsap_len); 


unbind, detach, and close 


void 

cleanup(fd) 

int fd; 

{ 

dl_unbind_req_t 

dl_detach_req_t 


/* file descriptor */ 

*unbind_req = (dl unbind req t 
*detach_req = (dl_detach_req_t 


*)ctrl_area; 
*)ctrl_area; 


/* unbind */ 

unbind_req->dl_primitive = DL_UNBIND_REQ; 
put_ctrl(fd, sizeof(dl_unbind_req_t) , 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 


/* detach */ 

detach_req->dl_primitive = DL_DETACH_REQ; 
put_ctrl(fd, sizeof(dl_detach_req_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 


/* close */ 
close(fd); 




send a connect request to a DLSAP 


void 

connect_req(fd, dlsap, dlsap_len) 


int fd; 

u_char *dlsap; 
int dlsap_len; 

{ 

dl_connect_req_t 
dl_connect_res_t 
u_char *tdlsap; 


/* file descriptor */ 

/* DLSAP to connect with */ 
/* length of dlsap */ 

*con_req = (dl_connect_req_t 
*con_res = (dl_connect_res_t 


*)ctrl_area; 
*)ctrl_area; 


/* fill in the connect request */ 
con req->dl primitive = DL_CONNECT_REQ; 
con_req->dl_dest_addr_length = dlsap_len; 
con_req->dl_dest_addr_offset = sizeof(dl connect req t); 

/* QOS is not supported; these fields must be set to zero */ 
con_req->dl_qos_length = 0; 
con_req->dl_qos_offset = 0; 
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con_req->dl_growth = 0; 

/* copy in the dlsap */ 

tdlsap = (u_char *)ctrl_area + con_req->dl_dest_addr_offset; 
memcpy(tdlsap, dlsap, dlsap_len); 

/* send the connect request */ 

print_dlsap("sending CONNECT_REQ to DLSAP ", dlsap, dlsap_len); 
put_ctrl(fd, sizeof(dl_connect_req_t) t dlsap_len, 0); 


get a connection response token for a stream; returns the token 


u_long 

get_token(fd) 

int fd; 

{ 

dl_token_req_t 

dl_token_ack_t 


/* file descriptor */ 


*tok_req = (dl_token_req_t *)ctrl_area; 
*tok_ack = (dl_token_ack_t *)ctrl_area; 


/* 

Send down a token request. Note that unlike most of the other 
messages this one is a PCPROTO message so we call put_ctrl with 
RS_HIPRI instead of zero. 

*/ 

tok req->dl primitive = DL_TOKEN_REQ; 
put_ctrl(fd, sizeof(dl token req t), RS_HIPRI); 


/* wait for the token ack */ 
get_msg(fd); 

check_ctrl(DL_TOKEN_ACK); 


/* return the token */ 
return(tok_ack->dl_token); 


^i(iri(ici(iri(ici(iri(ici(iri(ici(-k-k-k-k-k-k-ki(-k-k-ki(-k-k-ki(-k-k-ki('k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k 

get a connect indication from a stream; returns the correlation number 


u_long 

connect_ind(fd) 

int fd; 

{ 

dl_connect_ind_t 
u_char *dlsap; 
int dlsap_len; 


/* file descriptor */ 

*con_ind = (dl_connect_ind_t *)ctrl_area; 


/* wait for the connect indication */ 
get_msg(fd); 

check_ctrl(DL_CONNECT_IND); 


/* print the calling DLSAP */ 

dlsap = (u_char *)ctrl_area + con_ind->dl_calling_addr_offset; 
dlsap_len = con_ind->dl_calling_addr_length; 

print_dlsap("received CONNECT_IND from DLSAP ", dlsap, dlsap_len); 
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/* return the correlation number */ 
return(con_ind->dl_correlation); 


send a connect response with a specified correlation and token; 
wait for the OK_ACK 

■kic-kici<-k-k-k-kic-k-ki<ic-k-k-kic-kici<-k-k-kir-k-k-ki<-k-k-ki<ic-kici<-k-kici<ic-k-k-k-k*-k*-k*-k-k-k*-k-k-k*-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 


void 

connect_res(fd, 
int 

u_long 


correlation, 

fd; 

correlation; 


{ 


u_long token; 
dl_connect_res_t 


token) 

/* file descriptor */ 

/* correlation number of CONNECT_IND */ 

/* being responded to */ 

/* token of stream to pass connection to */ 

*con_res = (dl_connect_res_t *)ctrl_area; 


/* fill in the connect response */ 
con res->dl primitive = DL_CONNECT_RES; 
con_res->dl_correlation = correlation; 
con_res->dl_resp_token = token; 

/* QOS is not supported; these fields must be set to zero */ 
con_res->dl_qos_length = 0; 
con_res->dl_qos_offset = 0; 
con_res->dl_growth = 0; 


put_ctrl(fd, sizeof(dl_connect_res_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 


send a DISCONNECT_REQ and wait for the OK_ACK 


void 

disconnect_req(fd) 
int fd; 

{ 


dl_disconnect_req_t 


/* file descriptor */ 

*disc_req = (dl_disconnect_req_t *)ctrl_area; 


/* fill in the disconnect request */ 
disc_req->dl_primitive = DL_DISCONNECT_REQ; 

/* this is a normal disconnect */ 
disc_req->dl_reason = DL_DISC_NORMAL_CONDITION; 

/* 

Since we are not rejecting a CONNECT_IND, we set the correlation 
to zero. 
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*/ 

disc_req->dl_correlation = 0; 

/* send the disconnect request */ 
put_ctrl(fd, sizeof(dl_disconnect_req_t), 0); 

/* wait for the OK_ACK */ 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 




main() { 


main 

int 

send_fd; 

int 

recv_c_fd; 

int 

recv_d_fd; 

u_char 

sdlsap[20]; 

u_char 

rcdlsap[20] ; 

u_char 

rddlsap [20] ; 

int 

sdlsap_len. 

u_long 

correlation; 

u_long 

token; 

int 

i; 

/* 



/* file descriptor for sending stream */ 
/* fd for recv Ctrl stream */ 

/* fd for recv data stream */ 

/* sending DLSAP */ 

/* receiving control DLSAP */ 

/* receiving data DLSAP */ 

Lsap_len, rddlsap_len; /* DLSAP lengths 
/* correlation number for CONNECT_IND */ 
/* token for recv_d stream */ 

/* loop counter */ 


We'll use three streams: a sending stream, a receiving stream bound 
with max_conind = 1 (the "control" stream), and a receiving stream 
bound with max_conind = 0 (the "data" stream). The connect indication 
will be handed off from the control stream to the data stream. 

We initially open only the sending stream and the receiving control 
stream. 

*/ 


/* 

First, we must open the DLPI device file, /dev/dlpi, and attach 
to a PPA. attach will open /dev/dlpi, find the first PPA 
with the DL_HP_PPA_INFO primitive, and attach to that PPA. 
attach () returns the file descriptor for the stream. 

*/ 

send_fd = attach(); 
recv_c_fd = attach(); 

/* 

Now we must bind the streams to saps. The bind function will 
return the local DLSAP and its length for each stream in the last 
two arguments. Only the receiving control stream has a non-zero 
max_conind. 

*/ 

bind(send_fd, SFND_SAP, 0, DL_CODLS, sdlsap, &sdlsap_len); 
bind(recv_c_fd, RFCV_SAP, 1, DL_CODLS, rcdlsap, &rcdlsap_len); 

/* 

Start the connection establishment process by sending a CONNECT_RFQ 
from the sender to the receiver control stream. 

*/ 
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connect_req(send_fd, rcdlsap, rcdlsap_len); 

/* 

The receiver control stream gets a CONNECT_IND. We need the 
correlation number to relate the CONNECT_IND to the CONNECT_RES 
we will send down later. 

*/ 

correlation = connect_ind(recv_c_fd); 

/* 

We want to handle the actual data transfer over a dedicated 
receiver stream. Here, we attach and bind a second stream on 
the receivers sap with max_conind = 0. 

*/ 

recv_d_fd = attach(); 

bind(recv_d_fd, RECV_SAP, 0, DL_CODLS, rddlsap, &rddlsap_len); 

/* 

To pass the connection from the control stream to the data stream, 
we need a token for the data stream. get_token returns this. 

*/ 

token = get_token(recv_d_fd); 

/* 

Now we do a CONNECT_RES on the control stream. The correlation 
specifies the CONNECT_IND we are responding to, and the token, 
since it is non-zero, specifies the stream to which we want to 
hand off the connection. 

*/ 

connect_res(recv_c_fd, correlation, token); 

/* Get the CONNECT_CON back on the senders stream */ 

get_msg(send_fd); 

check_ctrl(DL_CONNECT_CON); 

printf("connection establishedXn"); 

/* 

We now have a connection established between the send_fd stream and 
the recv_d_fd stream. The recv_c_fd stream is in the IDLE state 
and is ready to process another CONNECT_IND. Since we won't be 
establishing any new connections, we'll call cleanup on the 
receiver control stream to unbind, detach, and close the file 
descriptor. 

*/ 

cleanup(recv_c_fd) ; 

/* Fill in data_area with some data to send. */ 
for(i =0; i < 60; i++) { 

data_area[i] = i; 

} 

/* Send 5 packets of data. */ 
for(i =0; i < 5; i++) { 

put_data(send_fd, (i + 1) * 10); 

printf ("sent %d bytes of data\n", (i + 1) * 10); 

} 
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/* Receive the 5 packets. */ 
for(i =0; i < 5; i++) { 

if(get_msg(recv_d_fd) != GOT_DATA) { 

printf("error : didn't get data\n"); 
check_ctrl(0); 
exit (1) ; 

} 

printf("received %d bytes of data\n", data_buf.len); 

} 

/* 

We're finished. Now we tear down the connection. We'll send 
a DISCONNECT_REQ on the receiver side. 

*/ 

disconnect_req(recv_d_fd); 

/* and receive the DISCONNECT_IND on the sender side. */ 

get_msg(send_fd); 

check_ctrl(DL_DISCONNECT_IND); 

/* And finally, we tear down the sender and receiver streams */ 
cleanup(send_fd); 
cleanup(recv_d_fd) ; 
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(C) COPYRIGHT HEWLETT-PACKARD COMPANY 1992. ALL RIGHTS 
RESERVED. NO PART OF THIS PROGRAM MAY BE PHOTOCOPIED, 

REPRODUCED, OR TRANSLATED TO ANOTHER PROGRAM LANGUAGE WITHOUT 
THE PRIOR WRITTEN CONSENT OF HEWLETT PACKARD COMPANY 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

The main part of this program is composed of two parts. 

The first part demonstrates data transfer over a connectionless 
stream with LLC SAP headers. The second part of this program 
demonstrates data transfer over a connectionless stream with 
LLC SNAP headers. 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

tinclude <stdio.h> 
tinclude <fcntl.h> 
tinclude <memory.h> 
tinclude <sys/types.h> 
tinclude <sys/stream.h> 
tinclude <sys/stropts.h> 
tinclude <sys/dlpi.h> 
tinclude <sys/dlpi_ext.h> 

tdefine SEND_SAP 0x80 /* sending SAP */ 

tdefine RECV_SAP 0x82 /* receiving SAP */ 

tdefine SNAP_SAP OxAA /* SNAP SAP */ 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

SNAP protocol values. 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

u_char SEND_SNAP_SAP[5] = {0x50, 0x00, 0x00, 0x00, 0x00}; 
u_char RECV_SNAP_SAP[5] = (0x60, 0x00, 0x00, 0x00, 0x00}; 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

global areas for sending and receiving messages 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

tdefine AREA_SIZE 5000 /* bytes; big enough for largest possible msg */ 

tdefine LONG_AREA_SIZE (AREA_SIZE / sizeof(u_long)) /* AREA_SIZE / 4 */ 

u_long ctrl_area[LONG_AREA_SIZE]; /* for control messages */ 

u_long data_area[LONG_AREA_SIZE]; /* for data messages */ 

struct strbuf ctrl_buf = { 

AREA_SIZE, 

0, 

ctrl_area 

}; 

struct strbuf data_buf = { 


/* maxlen = AREA_SIZE */ 

/* len gets filled in for each message */ 
/* buf = control area */ 
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AREA_SIZE, 

0 , 

data_area 

}; 

^■k-k-k-k-k-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-kic-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

get the next message from a stream; get_msg() returns one of the 
following defines 

ici^i^i^ici^iri^ici^iri^ici^ici^iri^iri^ic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k^ 


#define 

GOT_ 

_CTRL 

1 

/* message has only a control part */ 

#define 

GOT_ 

_DATA 

2 

/* message has only a data part */ 

#define 

GOT_ 

_BOTH 

3 

/* message has both control and data parts 

int 






get_msg 

(fd) 





f 

int 

M-l 


/* 

file descriptor */ 

i 

int 

flags = 

0; 

/* 

0 -> get any available message */ 


int 

result 

= 0; 

/* 

return value */ 


/* 






zero first byte of control area so the caller can call check_ctrl 
without checking the get_msg return value; if there was only data 
in the message and the user was expecting control or control + data, 
then when he calls check_ctrl it will compare the expected primitive 
zero and print information about the primitive that it got. 

*/ 

ctrl_area[0] = 0; 

/* call getmsg and check for an error */ 
if(getmsg(fd, &ctrl_buf, &data_buf, Sflags) < 0) { 

printf ("error: getmsg failed, errno = %d\n", errno); 
exit (1) ; 

} 

if(ctrl_buf.len > 0) { 

result 1= GOT_CTRL; 

} 

if(data_buf.len >0) { 

result 1= GOT_DATA; 

} 

return(result) ; 

} 


/* maxlen = AREA_SIZE */ 

/* len gets filled in for each message */ 
/* buf = data area */ 


check that control message is the expected message 

void 


check_ctrl(ex prim) 

int ex_prim; 


{ 


/* 


dl_error_ack_t *err_ack = 


the expected primitive */ 
(dl_error_ack_t *)ctrl_area; 


/* did we get the expected primitive? */ 
if(err_ack->dl_primitive != ex_prim) { 

/* did we get a control part */ 
if(ctrl_buf.len) { 

/* yup; is it an ERR0R_ACK? */ 
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if(err_ack->dl_primitive == DL_ERROR_ACK) { 

/* yup; format the ERROR_ACK info */ 
printf ("error: expected primitive 0x%02x, ", 
ex_prim); 

printf ("got DL_ERROR_ACK\n") ; 

printf (" dl_error_primitive = 0x%02x\n", 

err_ack->dl_error_primitive); 
printf (" dl_errno = 0x%02x\n", 

err_ack->dl_errno); 
printf (" dl_unix_errno = %d\n", 

err_ack->dl_unix_errno); 


exit (1) ; 


} else { 

/* 

didn't get an ERROR_ACK either; print whatever 
primitive we did get 
*/ 

printf("error: expected primitive 0x%02x, ", 
ex_prim); 

printf("got primitive 0x%02x\n", 

err_ack->dl_primitive); 

exit (1) ; 


} else { 

/* no control; did we get data? */ 
if(data_buf.len) { 

/* tell user we only got data */ 

printf("error: check_ctrl found only data\n"); 
exit (1) ; 

} else { 

/* 

no message???; well, it was probably an 
interrupted system call 
*/ 

printf("error: check_ctrl found no message\n"); 
exit (1) ; 


put a message consisting of only a data part on a stream 

void 

put_data(fd, length) 

int fd; /* file descriptor */ 

int length; /* length of data message */ 
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{ 

/* set the len field in the strbuf structure */ 
data_buf.len = length; 

/* call putmsg and check for an error */ 
if(putmsg(fd, 0, &data_buf, 0) < 0) { 

printf("error: put_data putmsg failed, errno = %d\n", errno); 
exit (1) ; 



put a message consisting of only a control part on a stream 

void 


put_ctrl(fd. 

length, pri) 



int 

fd; 

/* 

file descriptor */ 

int 

length; 

/* 

length of control message */ 

int 

pri; 

/* 

priority of message: either 0 or RS_HIPRI */ 


{ 

/* set the len field in the strbuf structure */ 
ctrl_buf.len = length; 


/* call putmsg and check for an error */ 
if(putmsg(fd, &ctrl_buf, 0, pri) < 0) { 

printf("error: put_ctrl putmsg failed, errno = %d\n", errno); 
exit (1) ; 





put a message consisting of both a control part and a control part 
on a stream 

■kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kici’:-k-kic-k-k-kic-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-ki<^-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

void 

put_both(fd, ctrl_length, data_length, pri) 


int 

fd; 

/* 

file descriptor */ 

int 

ctrl_length; 

/* 

length of control part */ 

int 

data_length; 

/* 

length of data part */ 

int 

pri; 

/* 

priority of message: either 0 or RS_HIPRI 


/* set the len fields in the strbuf structures */ 
ctrl_buf.len = ctrl_length; 
data_buf.len = data_length; 


/* call putmsg and check for an error */ 
if(putmsg(fd, &ctrl_buf, &data_buf, pri) < 0) { 

printf("error: put_both putmsg failed, errno = %d\n", errno); 
exit (1) ; 



open the DLPI cloneable device file, get a list of available PPAs, 
and attach to the first PPA; returns a file descriptor for the stream 

int 
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attach () { 

int fd; /* file descriptor */ 

int ppa; /* PPA to attach to */ 

dl_hp_ppa_req_t *ppa_req = (dl_attach_req_t *)ctrl_area; 
dl hp ppa ack t *ppa_ack = (dl hp ppa ack t *)ctrl_area; 
dl hp ppa info t *ppa_info; 

dl_attach_req_t *attach_req = (dl_attach_req_t *)ctrl_area; 
char *mac_name; 

/* open the device file */ 

if((fd = open("/dev/dlpi", 0_RDWR)) == -1) { 

printf("error: open failed, errno = %d\n", errno) ; 
exit (1) ; 

} 


/* 

find a PPA to attach to; we assume that the first PPA on the 
remote is on the same media as the first local PPA 
*/ 

/* send a PPA_REQ and wait for the PPA_ACK */ 
ppa_req->dl_primitive = DL_HP_PPA_REQ; 
put_ctrl(fd, sizeof(dl_hp_ppa_req_t), 0); 
get_msg(fd); 

check_ctrl(DL_HP_PPA_ACK); 

/* make sure we found at least one PPA */ 
if(ppa_ack->dl_length == 0) { 

printf("error: no PPAs available\n"); 
exit (1) ; 

} 

/* examine the first PPA */ 

ppa_info = (dl hp ppa info t *)((u_char *)ctrl_area + 
ppa_ack->dl_offset) ; 
ppa = ppa_info->dl_ppa; 
switch(ppa_info->dl_mac_type) { 

case DL_CSMACD: 
case DL_ETHER: 

mac_name = "Ethernet"; 
break; 

case DL_TPR: 

mac_name = "Token Ring"; 
break; 

case DL_FDDI: 

mac_name = "FDDI"; 
break; 

default: 

printf ("error: unknown MAC type in ppa_info\n"); 
exit (1) ; 

} 

printf("attaching to %s media on PPA %d\n", mac_name, ppa); 

/* 

fill in ATTACH_REQ with the PPA we found, send the ATTACH_REQ, 
and wait for the OK_ACK 
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*/ 

attach_req->dl_primitive = DL_ATTACH_REQ; 
attach_req->dl_ppa = ppa; 

put_ctrl(fd, sizeof(dl_attach_req_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 

/* return the file descriptor for the stream to the caller */ 
return(fd); 

} 

bind to a sap with a specified service mode and max_conind; 
returns the local DLSAP and its length 

void 

bind(fd, sap, max_conind, service_mode, dlsap, dlsap_len) 
int fd; /* file descriptor */ 

int sap; /* 802.2 SAP to bind on */ 

int max_conind; /* max # of connect indications to accept */ 

int service_mode; /* either DL_CODLS or DL_CLDLS */ 

u_char *dlsap; /* return DLSAP */ 

int *dlsap_len; /* return length of dlsap */ 

{ 

dl_bind_req_t *bind_req = (dl bind reg t *)ctrl_area; 
dl_bind_ack_t *bind_ack = (dl_bind_ack_t *)ctrl_area; 
u_char *dlsap_addr; 

/* fill in the BIND_REQ */ 
bind_req->dl_primitive = DL_BIND_REQ; 
bind_req->dl_sap = sap; 
bind_req->dl_max_conind = max_conind; 
bind_req->dl_service_mode = service_mode; 

bind_req->dl_conn_mgmt = 0; /* conn_mgmt is NOT supported */ 

bind_req->dl_xidtest_fIg =0; /* user will handle TEST & XID pkts */ 

/* send the BIND_REQ and wait for the 0K_ACK */ 
put_ctrl(fd, sizeof(dl_bind_req_t), 0); 
get_msg(fd); 

check_ctrl(DL_BIND_ACK); 

/* return the DLSAP to the caller */ 

*dlsap_len = bind_ack->dl_addr_length; 

dlsap_addr = (u_char *)ctrl_area + bind_ack->dl_addr_offset; 
memcpy(dlsap, dlsap_addr, *dlsap_len); 

} 

bind to a SNAP sap via the DL_PEER_BIND, or DL_HIERARCHICAL_BIND 
subsequent bind class; returns the local DLSAP and its length 

void 

subs_bind(fd, snapsap, snapsap_len, subs_bind_class, dlsap, dlsap_len) 

int fd; 

u_char *snapsap; 

int subs_bind_class; 

u_char *dlsap; 
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int *dlsap_len; 

{ 

dl_subs_bind_req_t *subs_bind_req = (dl_subs_bind_req_t*)ctrl_area; 

dl_subs_bind_ack_t *subs_bind_ack = (dl_subs_bind_ack_t*)ctrl_area; 

u_char *dlsap_addr; 

/* Fill in Subsequent bind req */ 
subs bind req->dl primitive = DL_SUBS_BIND_REQ; 
subs_bind_req->dl_subs_sap_offset = DL_SUBS_BIND_REQ_SIZE; 
subs_bind_req->dl_subs_sap_length = snapsap_len; 
subs_bind_req->dl_subs_bind_class = subs_bind_class; 
memcpy((caddr_t)&subs_bind_req[1], snapsap, snapsap_len); 

/* send the SUBS_BIND_REQ and wait for the OK_ACK */ 
put_ctrl(fd, sizeof(dl_subs_bind_req_t)+snapsap_len, 0); 
get_msg(fd); 

check_ctrl(DL_SUBS_BIND_ACK); 

/* return the DLSAP to the caller */ 

*dlsap_len = subs_bind_ack->dl_subs_sap_length; 

dlsap_addr = (u_char *)ctrl_area + subs_bind_ack->dl_subs_sap_offset; 
memcpy(dlsap, dlsap_addr, *dlsap_len); 


unbind, detach, and close 


void 

cleanup(fd) 

int fd; 

{ 

dl_unbind_req_t 

dl_detach_req_t 


/* file descriptor */ 

*unbind_req = (dl unbind req t 
*detach_req = (dl_detach_req_t 


*)ctrl_area; 
*)ctrl_area; 


/* unbind */ 

unbind_req->dl_primitive = DL_UNBIND_REQ; 
put_ctrl(fd, sizeof(dl_unbind_req_t) , 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 


/* detach */ 

detach_req->dl_primitive = DL_DETACH_REQ; 
put_ctrl(fd, sizeof(dl_detach_req_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 


/* close */ 
close(fd); 


receive a data packet; 

int 

recv_data(fd) 

int fd; /* file descriptor */ 
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{ 

dl_unitdata_ind_t *data_ind = (dl_unitdata_ind_t *)ctrl_area; 

char *rdlsap; 

int msg_res; 

msg_res = get_msg(fd); 
check_ctrl(DL_UNITDATA_IND); 
if(msg_res != GOT_BOTH) { 

printf ("error: did not receive data part of messageXn") ; 
exit (1) ; 

} 

return(data_buf.len); 

} 

^■k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-^ 

send a data packet; assumes data_area has already been filled in 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

void 

send_data(fd, rdlsap, rdlsap_len, len) 

int fd; /* file descriptor */ 

u_char *rdlsap; /* remote dlsap */ 

int rdlsap_len; /* length of rdlsap */ 

int len; /* length of the packet to send */ 

{ 

dl_unitdata_req_t *data_req = (dl_unitdata_req_t *)ctrl_area; 

u_char *out_dlsap; 

/* fill in data_req */ 

data_req->dl_primitive = DL_UNITDATA_REQ; 
data_req->dl_dest_addr_length = rdlsap_len; 
data_req->dl_dest_addr_offset = sizeof(dl_unitdata_req_t); 

/* copy dlsap */ 

data_req->dl_priority.dl_min = 0; 
data_req->dl_priority.dl_max = 0; 

out_dlsap = (u_char *)ctrl_area + sizeof(dl_unitdata_req_t); 
memcpy(out_dlsap, rdlsap, rdlsap_len); 

put_both(fd, sizeof(dl_unitdata_req_t) + rdlsap_len, len, 0); 

} 

^■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

print a string followed by a DLSAP 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

void 

print_dlsap(string, dlsap, dlsap_len) 

char *string; /* label */ 

u_char *dlsap; /* the DLSAP */ 

int dlsap_len; /* length of dlsap */ 

{ 

int i; 

printf ("%s", string); 
for(i =0; i < dlsap_len; i++) { 

printf("%02x", dlsap[i]); 

} 

printf("\n"); 

} 
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/■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 


main 



kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

main () 

{ 




int 

send_fd, recv_fd; 


u_char 

sdlsap[20]; 



u_char 

rdlsap[20] ; 



int 

sdlsap_len. 

rdlsap_le 


int 

i, j, recv_ 

len; 


■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

/* file descriptors */ 

/* sending DLSAP */ 

/* receiving DLSAP */ 
n; /* DLSAP lengths */ 


/* 

PART 1 of program. Demonstrate connectionless data transfer with 
LLC SAP header. 

*/ 


/* 

First, we must open the DLPI device file, /dev/dlpi, and attach 
to a PPA. attachO will open /dev/dlpi, find the first PPA 
with the DL_HP_PPA_INFO primitive, and attach to that PPA. 
attach () returns the file descriptor for the stream. Here we 
do an attach for each file descriptor. 

*/ 

send_fd = attachO; 
recv_fd = attachO; 


/* 

Now we have to bind to a lEEESAP. We will ask for connectionless data 
link service with the DL_CLDLS service mode. Since we are 
connectionless, we will not have any incoming connections so we 
set max_conind to 0. bind() will return our local DLSAP and its 
length in the last two arguments we pass to it. 

*/ 

bind(send_fd, SEND_SAP, 0, DL_CLDLS, sdlsap, &sdlsap_len); 
bind(recv_fd, RECV_SAP, 0, DL_CLDLS, rdlsap, &rdlsap_len); 

/* print the DLSAPs we got back from the binds */ 
print_dlsap("sending DLSAP = ", sdlsap, sdlsap_len); 

print_dlsap("receiving DLSAP = ", rdlsap, rdlsap_len); 


/* 

Time to 
*/ 

for(i = 


send some data. We'll send 5 data packets in sequence. 

0; i < 5; i++) { 

/* send (i+1)*10 data bytes with the first byte = i */ 
data_area[0] = i; 

/* Initialize data area */ 
for (j = 1; j < (i+l)*10; j++) 

data_area[j] = "a"; 

print_dlsap("sending data to ",rdlsap, rdlsap_len); 
send_data(send_fd, rdlsap, rdlsap_len, (i+1) * 10); 

/* receive the data packet */ 
recv_len = recv_data(recv_fd); 

printf("received %d bytes, first word = %d\n", recv_len, 
data_area[0]); 
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/* 

We're finished with PART 1. Now call cleanup to unbind, then detach, 
then close the device file. 

*/ 

cleanup(send_fd); 
cleanup(recv_fd) ; 

/* 

PART 2 of program. Demonstrate connectionless data transfer with 
LLC SNAP SAP header. 

*/ 

/* 

As demonstrated in the first part of this program we must first 
open the DLPI device file, /dev/dlpi, and attach to a PPA. 

*/ 

send_fd = attach(); 
recv_fd = attach(); 

/* 

The first method for binding a SNAP protocol value (which is 
demonstrated below) requires the user to first bind the SNAP 
SAP OxAA, then issue a subsequent bind with class DL_HIERARCHICAL_BIND 
with the 5 bytes of SNAP information. 

The second method (which is not demonstrated in this program) is 
to bind any supported protocol value (see section 5) and then issue 
a subsequent bind with class DL_PEER_BIND. The data area of the 
subsequent bind should include 6 bytes of data, the first byte being 
the SNAP SAP OxAA followed by 5 bytes of SNAP information. 

*/ 

bind(send_fd, SNAP_SAP, 0, DL_CLDLS, sdlsap, &sdlsap_len); 
bind(recv_fd, SNAP_SAP, 0, DL_CLDLS, rdlsap, &rdlsap_len); 

/* 

Now we must complete the binding of the SNAP protocol value 
with the subsequent bind request and a subsequent bind class 
of DL_HIERARCHICAL_BIND. 

*/ 

subs_bind(send_fd, SEND_SNAP_SAP, 5, DL_HIERARCHICAL_BIND, sdlsap, 

&sdlsap_len); 

subs_bind(recv_fd, RECV_SNAP_SAP, 5, DL_HIERARCHICAL_BIND, rdlsap, 

&rdlsap_len); 

/* print the DLSAPs we got back from the binds */ 
print_dlsap("sending DLSAP = ", sdlsap, sdlsap_len); 

print_dlsap("receiving DLSAP = ", rdlsap, rdlsap_len); 

/* 

Time to send some data. We'll send 5 data packets in sequence. 

*/ 

for(i =0; i < 5; i+t) { 

/* send (itl)*10 data bytes with the first byte = i */ 
data_area[0] = i; 

/* Initialize data area */ 
for (j = 1; j < (i+l)*10; j++) 

data_area[j] = "a"; 
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print_dlsap("sending data to ",rdlsap, 
send_data(send_fd, rdlsap, rdlsap_len, 
/* receive the data packet */ 
recv_len = recv_data(recv_fd) ; 
printf("received %d bytes, first word 
data_area[0]); 


rdlsap_len); 

(i + 1) * 10) ; 


= %d\n", recv_len. 


/* 

We're finished. Now call cleanup to unbind, then detach, 
then close the device file. 

*/ 

cleanup(send_fd); 
cleanup(recv_fd) ; 
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/* 

* (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1993. ALL RIGHTS 

* RESERVED. NO PART OF THIS PROGRAM MAY BE PHOTOCOPIED, 

* REPRODUCED, OR TRANSLATED TO ANOTHER PROGRAM LANGUAGE WITHOUT 

* THE PRIOR WRITTEN CONSENT OF HEWLETT PACKARD COMPANY 
*/ 


The program demonstrates RAW mode data transfer over an 
802.3 interface. 

-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

tdefine PPA I 

tdefine FRAME_LEN 1500 /* max message size is 1514;MAC+LLC+data */ 
tdefine SEQ_OFFSET 100 
tdefine INSAP 22 
tdefine OUTSAP 24 


tdefine OUTER_LOOPS 10 
tdefine INNER_LOOPS 25 


tinclude 

tinclude 

tinclude 

tinclude 

tinclude 

tinclude 

tinclude 

tinclude 


<sys/types.h> 
<fcntl.h> 
<errno.h> 
<stdio.h> 
<string.h> 
<signal.h> 
<math.h> 
<ctYpe.h> 


tinclude 

tinclude 

tinclude 

tinclude 

tinclude 

tinclude 


<sys/stream.h> 

<sys/Stropts.h> 
<sys/poll.h> 
<sys/dlpi.h> 
<sys/dlpi_ext.h> 
<netinet/if_ieee.h> 


tdefine bcopy(source, destination, length) memcpy(destination, source, 
tdefine ETHER_HLEN 14 


char tag[80]; 

tdefine AREA_SZ 5000 /*-=-* buffer length in bytes *-=-*/ 

u_long ctl_area[AREA_SZ]; 
u_long dat_area[AREA_SZ]; 

struct strbuf ctl = {AREA_SZ, 0, ctl_area}; 
struct strbuf dat = {AREA_SZ, 0, dat_area}; 

tdefine GOT_CTRL 1 


length) 
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tdefine GOT_DATA 2 

tdefine GOT_BOTH 3 

tdefine GOT_INTR 4 

/*-=-* get a message from a stream; return type of message *-=-*/ 
int 

get_msg(fd) 

int fd; 

{ 

int flags = 0; 

int res, ret; 

ctl_area[0] = 0; 
dat_area[0] = 0; 
ret = 0; 

res = getmsg(fd, &ctl, &dat, Sflags); 

if (res < 0) { 

if(errno == EINTR) { 
return(GOT_INTR) ; 

} else { 

printf("%s,get_msg: getmsg failed, errno = %d\n", tag, 
exit (1) ; 


if(ctl.len >0) { 

ret 1= GOT_CTRL; 

} 

if(dat.len >0) { 

ret I= GOT_DATA; 

} 

return(ret); 


/*-=-* verify that dl_primitive in ctl_area = prim *-=-*/ 
int 

check_ctrl(prim) 
int prim; 

{ 

dl_error_ack_t *err_ack = (dl_error_ack_t *)ctl_area; 

if(err_ack->dl_primitive != prim) { 

if(err_ack->dl_primitive == DL_ERROR_ACK) { 

printf("%s,check_ctrl: got DL_ERROR_ACK\n",tag); 
printf (" dl error primitive = 0x%02x\n", 
err ack->dl error primitive); 


errno); 
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printf(" dl_errno = 0x%02x\n", err_ack->dl_errno); 
printf(" dl_unix_errno = %d\n", err_ack:->dl_unix_errno); 
exit (1); 

} else { 

printf("%s,check_ctrl: expected primitive 0x%02x", tag, prim); 
printf(", got primitive 0x%02x\n", err_ack->dl_primitive); 
exit (1); 



/*-=-* put a control message on a stream *-=-*/ 
void 

put_ctrl(fd, len, pri) 

int fd, len, pri; 

{ 

ctl.len = len; 

if(putmsg(fd, &ctl, 0, pri) < 0) { 

printf("%s,put_ctrl: putmsg failed, errno = %d\n", tag, errno); 
exit (1) ; 



/*-=-* put a control t data message on a stream *-=-*/ 
void 

put_both(fd, clen, dlen, pri) 

int fd, clen, dlen, pri; 

{ 

ctl.len = clen; 
dat.len = dlen; 

if (putmsg(fd, &ctl, &dat, pri) < 0) { 

printf("%s,put_both: putmsg failed, errno = %d\n", tag, errno); 
exit (1) ; 

} 

} 

/*-=-* open file descriptor and attach *-=-*/ 
int 

dl_open(ppa) 

int ppa; 

{ 

int fd; 

dl_attach_req_t *attach_req = (dl_attach_req_t *)ctl_area; 

if((fd = open("/dev/dlpi", 0_RDWR)) == -1) { 

printf("%s,dl_open: open failed, errno = %d\n",tag, errno); 
exit (1) ; 

} 

attach_req->dl_primitive = DL_ATTACH_REQ; 
attach_req->dl_ppa = ppa; 

put_ctrl(fd, sizeof(dl_attach_req_t), 0); 
get_msg(fd); 
check_ctrl(DL_OK_ACK); 
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return(fd); 

} 


/*-=-* send DL_BIND_REQ *-=-*/ 
void 

dl_bind(fd, sap, addr) 
int fd, sap; 

u_char *addr; 

{ 

dl_bind_req_t *bind_req = (dl bind req t *)ctl_area; 
dl_bind_ack_t *bind_ack = (dl_bind_ack_t *)ctl_area; 

bind_req->dl_primitive = DL_BIND_REQ; 
bind_req->dl_sap = sap; 
bind_req->dl_max_conind = 1; 
bind_req->dl_service_mode = DL_HP_RAWDLS; 
bind_req->dl_conn_mgmt = 0; 
bind_req->dl_xidtest_fIg = 0; 

put_ctrl(fd, sizeof(dl_bind_req_t), 0); 
get_msg(fd); 

check_ctrl(DL_BIND_ACK); 


bcopy((u_char *)bind_ack + bind_ack->dl_addr_offset, 
bind_ack->dl_addr_length); 


addr. 


void XXX(); 
void 

main(argc, argv) 
int argc; 

char *argv[]; 

{ 

int infd, outfd; 
struct pollfd pinfo; 
int i, j, inseq; 
u_char addr[25]; 

struct ieee8023_hdr *mac_hdr = (struct ieee8023_hdr *)dat_area; 
struct ieee8022_hdr *llc_hdr; 

dl_hp_rawdata_req_t *rawdat_req = (dl hp rawdata req t *)ctl_area; 
dl_hp_rawdata_ind_t *rawdat_ind = (dl_hp_rawdata_ind_t *)ctl_area; 
dl_error_ack_t *err_ack = (dl_error_ack_t *)ctl_area; 

/* MAC header size is 14 bytes */ 

llc_hdr = (struct ieee8022_hdr *)&((u_char *)dat_area)[14]; 

if ( ! (infd = dl_open(PPA))) { 

printf("error: open failedXn"); 
exit (1) ; 

} 

if( ! (outfd = dl_open(PPA) )) ( 

printf("error : open failedXn"); 
exit (1) ; 

} 

dl_bind(infd, INSAP, addr); 
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dl_bind(outfd, OUTSAP, addr); 
pinfo.fd = outfd; 

pinfo.events = POLLIN | POLLPRI; 
pinfo.revents = 0; 

for(i =0; i < OUTER_LOOPS; i++) { 

for(j =0; j < INNER_LOOPS; j++) { 

bcopy(addr, mac_hdr->destaddr, 6); 

/* card will stuff in source addr 

* The ieee header length does not include the 

* ethernet MAC header. 

*/ 

mac_hdr->length = FRAME_LEN - ETHER_HLEN; 
llc_hdr->dsap = INSAP; 
llc_hdr->ssap = OUTSAP; 
llc_hdr->ctrl = IEEECTRL_DEF; 

sprintf(&dat_area[SEQ_OFFSET], "%d", 1 * INNER_LOOPS + j); 

rawdat_req->dl_primitive = DL_HP_RAWDATA_REQ; 
put_both(outfd, sizeof(dl hp rawdata reg t), FRAME_LEN, 0); 
printf("+"); 
fflush(stdout) ; 
if(poll(Spinfo, 1, 0)) { 

get_msg(outfd); 
check_ctrl(DL_ERROR_ACK); 

if(err_ack->dl_error_primitive != DL_HP_RAWDATA_REQ || 
err_ack->dl_errno != DL_SYSERR || 
err_ack->dl_unix_errno != ENOBUFS) { 
check_ctrl(0); 

} else { 

/* re-send same pkt */ 
printf("\nENOBUFS\n"); 

j—; 



for(j =0; j < INNER_LOOPS; j++) { 

get_msg(infd) ; 
printf("-") ; 
fflush(stdout) ; 

check_ctrl(DL_HP_RAWDATA_IND) ; 
if(dat.len != FRAME_LEN) { 

printf("\nlength error: expected %d, got %d\n", 
FRAME_LEN, dat.len); 

} 

inseq = strtol(&dat_area[SEQ_OFFSET], 0, 0); 
if(inseq != (i * INNER_LOOPS + j)) { 

printf("\nseq error: expected %d, got %d\n", 

1 * INNER_LOOPS + j, inseq); 


} 

printf("\n"); 
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Called DLS user The DLS 

user in connection mode that 
processes requests for 
connections from other DLS 
users. 

Calling DLS user The DLS 

user in connection mode that 
initiates the establishment of a 
data link connection. 

Communication endpoint 

The local communication 
channel between a DLS user 
and DLS provider. 

Connection establishment 

The phase in connection mode 
that enabies two DLS users to 
create a data link connections 
between them. 

Connectionless mode A 

mode of transfer i n which data 
is passed from one user to 
another in self-contained units 
with no logical relationship 
requi red among the units. 

Connection mode A circuit- 
oriented mode of transfer in 
which data is passed from one 
user to another over an 


established connection in a 
sequenced manner. 

Connection release The 

phase in connection mode that 
terminates a previously 
established data link 
connection. 

Data link service data 
unit A grouping of DLS user 
data whose boundaries are 
preserved from one end of a 
data link connection to the 
other. 

Data transfer The phase in 
connection and connectionless 
modethat supports thetransfer 
of data between two DLS users. 

DLSAP A point at which a DLS 
user attached itself to a DLS 
provider to access data link 
services. 

DLSAP address An identifier 
used to different!ate and locate 
specific DLS user access points 
to a DLS provider. 

DLS provider The data link 
layer protocol that provides the 
services of the Data Link 
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Provider Interface. 

DLS user The user-level 
application or user-level or 
kernel-level protocol that 
accessess the services of the 
data link layer. 

Local management The 

phase in connection and 
connectionless modes in which 
a DLS user initiates a stream 
and binds a DLSAP to the 
stream. Primitives in this 
phase generate local operations 
only. 

PPA The point at which a 
system attaches itself to a 
physical communications 
m^ium. 

PPA identifier An identifier 
of a particular physical medium 
over which communication 
transpires. 
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